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Preface 


This book is effectively two manuals in one: a system initialization SRL and a 
preliminary tuning guide. These two “‘manuals” are combined because of the need 
for heavy cross referencing between performance discussions and the descriptions 
of parameters and parmlib members that affect performance. The book isa 
pioneer effort in both areas: how to initialize the system, and how to get improved 
system performance. For best results, you should read this manual before you 
prepare your sysgen deck. 


Although it is basically an SRL, elements of logic are included for certain 
components: the System Resources Manager (SRM), the Auxiliary Storage Manager 
(ASM), and to some extent NIP and the Program Manager. The logic 
elements are provided either to clarify recommendations and “how it works” 
descriptions, or to provide a basis for possible internal modification. This is 
especially true of the chapter on the System Resources Manager. 


The manual consists of six parts or chapters. 


Part 1: Introduction 

Part 2: System Initialization 

Part 2.1: Auxiliary Storage Management Initialization 

Part 3: The System Resources Manager 

Part 4: How to Use the System Activity Measurement Facility (MF/1) 
Part 5: System Performance Factors 


Part 2, System Initialization, describes parmlib parameters and processes related 
to IPL, and certain system commands (START GTF, START MF1, SET IPS). It 
includes the meaning and use of each parameter, syntax rules, syntax examples, 
value ranges that are syntactically acceptable, default values, and performance 
notes where applicable. The chapter points the reader to extended discussions on 
related topics in Parts 3, 4, and 5. 


Part 2.1 describes auxiliary storage management (ASM) with respect to 
controlling the system’s use of page and swap data sets. It explores the concepts of 
paging and swap operations, examines the algorithms used, and explains how these 
algorithms influence the choice of optimum data set sizes. Six examples in the 
chapter illustrate typical system tuning problems involving the concepts, 
algorithms, and data set sizes previously discussed. The chapter then makes some 
performance recommendations and concludes with a series of questions commonly 
asked about ASM and the answers to them. 


Part 3 describes the types of control available through the system resources 
manager (SRM), the functions used to implement these controls, the concepts for 
using SRM parameters, and the parameters themselves, Part 3 also presents guide- 
lines for defining these parameters and describes several sample specifications. 
Finally, Part 3 provides a list of potential problems along with guidelines for 
evaluating and adjusting the parameters. 


Part 4 is a small “SRL” on the use of the System Activity Measurement Facility, 
MF/1. The chapter describes the parameters that control MF/1 reports and SMF 
records, discusses how MF/1 can be started (including the IBM-supplied cataloged 
procedure) and provides some possible uses for each of the system activity reports. 
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e TCAM Tuning Considerations 
e TSO and Batch Service Trade-offs Via the IPS 
e Miscellaneous Performance Guidelines 


The performance factors information in Part 5, plus performance hints in othe: 


parts of the manual, are preliminary projections based on design analysis. That is, 


the information is based on the designers’ best judgement of how the system should 


behave and the factors that should affect its performance. This preliminary 
performance information will be updated by Installation Newsletters after the 
manual is printed. The updates will provide tuning guidelines based on system 


measurements. 


Several of the performance topics in Part 5 use an experimental technique: 
inclusion of customer questions asked on these topics, followed by the answers. 


Related Publications 


The following manuals should be available for reference while you are reading this 


SRL: 
OS/VS System Management Facilities (SMF) 
OS/VS Utilities 


OS/VS2 Using OS Catalog Management with the Master 
Catalog: CVOL Processor 


OS/VS2 System Programming Library: System Generation 
Reference 


OS/VS2 Access Method Services 

OS/VS Virtual Storage Access Method Programmer’s Guide 

OS/VS2 TCAM Programmer’s Guide 

OS/VS System Programming Library: VTAM 

Operator’s Library: OS/VS2 Reference (JES2)} 

OS/VS2 System Programming Library: JES2 

OS/VS2 System Programming Library: JES3 System 
Programmer's Guide 

Operator’s Library: OS/VS2 Reference (JES3) 

Operator’s Library: OS/VS2 TCAM 

OS/VS2 Supervisor Services and Macro Instructions 

OS/VS2 System Programming Library: Job Management 

OS/VS2 System Programming Library: Supervisor 

OS/VS2 System Programming Library: TSO 

OS/VS2 System Programming Library: Storage Estimates 

OS/VS2 System Programming Library: Service Aids 

OS/VS2 JCL 

OS/VS Message Library: VS2 System Messages 

OS/VS Message Library: JES3 Messages 

OS/VS2 System Programming Library: Data Management 

OS/VS2 Conversion Notebook 


OS/VS Mass Storage System (MSS) Services for Space 
Management 


IBM System/360 and System/370 ASP Version 3 Asymmetric 
Multiprocessing System: System Programmer’s Manual 


ASP Version 3 Operator’s Manual 
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Operator’s Library: OS/VS2 TCAM 

OS/VS2 Supervisor Services and Macro Instructions 
OS/VS2 System Programming Library: Job Management 
OS/VS2 System Programming Library: Supervisor 
OS/VS2 System Programming Library: TSO 

OS/ VS2 System Programming Library: Storage Estimates 
OS/VS2 System Programming Library: Service Aids 
OS/VS2 ICL 

OS/VS Message Library: VS2 System Messages 

OS/VS Message Library: JES3 Messages 

OS/VS2 System Programming Library: Data Management 
OS/VS2 Conversion Notebook 


OS/VS Mass Storage System (MSS) Services for Space 
Management 


GC30-2046 
GC28-0683 
GC28-0627 
GC28-0628 
GC28-0629 
GC28-0604 
GC28-0674 
GC28-0692 
GC38-1002 
GC38-1012 
GC26-3830 
GC28-0689 


GC35-0012 


In this manual, any references made to an IBM program product are not 
intended to state or imply that only IBM’s program may be used; any functionally 
equivalent program may be used instead. This manual has references to the 


following IBM program products: 
RMF — Resource Measurement Facility 
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Summary of Amendments 
for GC28-0681-2 
VS2 Release 3.7 


The JES2 and JES3 Initialization sections and the JES2 Performance sections are no 
longer in this manual. For information about JES2 and JES3, refer respectively to 
OS/VS2 System Programming Library: JES2, GC23-0001, and OS/VS2 System 
Programming Library: JES3, GC28-0608. 


Changes have been made throughout this publication to reflect a Service Update - - 
OS/VS2 Release 3.7. In addition to general editorial changes, technical updated 
topics include: 


How to Control Parmlib 
Descriptions of Individual Parmlib Members: 


— COMMNDxx 
— JEABLDxx 
— JEALPAxx 
— TEASYSxx 
— LNKLSTxx 
— MVIKEYO00O 
— VATLSTxx 


I/O Load Adjusting Routine 

Main Storage Occupancy Routine 

Page Replacement Routine 

Device Allocation Routine 

How the System Resources Manager is Controlled 
Performance Objectives 

SRM Constants Related to the Resource Use Routines 
MF/1 Options 

Guidelines for the Effective Use of Paging Data Sets 
Pageable Link Pack Area 

Device Allocation Performance 

VSAM Catalog Performance 

The Use of GTF to Track Sysevents 
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Summary of Amendments 
for GC28-0681-1 

as Updated by GN28-2603 
VS2 Release 3 


This Technical Newsletter, a part of release 3 of OS/VS2, updates the initialization 
information for the Job Entry Subsystem 3 (JES3). In addition to general editorial 
changes, the following topics were technically updated: 


How to Control JES3 Initialization 
How JES3 Performs Initialization 
Creating an Initialization Data Set 
BUFFER 

CIPARM 

CLASS 

DEVICE 

DYNALLOC (new initialization card) 
JES3LIB 

MAINPROC 

OPTIONS 

PROC 

RESCTBLK (new initialization card) 
RJPTERM 

SELECT 

SETNAME 

STANDARDS 

SYSOUT 


Summary of Amendments 
for GC28-0681-1 
VS2 Release 3 


e@ Mass Storage System (MSS) adds a new member, MVIKEYOO, to SYS1.PARMLIB. 
MSS also adds the PURGE parameter and causes changes to the VAL parameter 
in the IEASYSxx member of SYS1.PARMLIB. 


@ Multi-Access Spool adds three new JES2 initialization parameters: 
&CHKPT, QCONTROL, and Sn. 


e JES3 Initialization is a new section that explains how to initialize JES3 and 
describes the JES3 initialization cards and their parameters. 


e Vary Storage adds a new parameter, RSU, to the IEASYSxx member of 
SYS1.PARMLIB. RSU allows the installation to specify the number of storage 
units that will be available for storage reconfiguration in an MP system. 


e@ Minor technical changes and additions were made throughout the publication. 


Note: JES3 and Mass Storage System information contained in this publication 
is for planning purposes only until the products become available. 
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Summary of Amendments 
for GC28-0681-1 

as Updated by GN28-2586 
VS2 Release 2 


This Technical Newsletter provides: 

e New IBM-supplied default Installation Performance Specifications (IPS). 

e@ Changes to many of the SRM examples and explanations in 
“Part 3: How to Use the System Resources Manager” because 
of the new default IPS. 

@ Changes to the Auxiliary Storage Manager (ASM) slot sorting algorithms 
for paging data sets. Also, an expanded explanation of how the PAGE 
parameter is used by ASM. 


e New tuning guidelines, some of which were previously printed in 
IBM Installation Newsletter Issue 74-09 (7/12/74). 


e@ Corrections of minor technical and typographical errors. 


Summary of Amendments 11 


12 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2 Release 3.7) 





VS2.03.807 


Part 1: General Introduction 


This manual discusses the following five general subject areas: 


e System initialization 

e Auxiliary storage manager 

@ The system resources manager 

e@ The system activity measurement facility (MF/1) 
e System performance factors 


System Initialization 


System initialization is the part of system tailoring that takes place after sysgen. 
The tailoring results from the specification of system parameters, first at IPL and 
then later when certain operator commands are issued. 


System tailoring is the overall process by which an installation selects its 
operating system. The process consists of the specification of system options 
through these mechanisms: 


e System generation 

e IPL-time selections 

e Certain operator commands after IPL 
e Implicit system parameters 


IPL-time choices that help to tailor the system can come from several sources: 


e Various types of IPLs. 

e@ Operator entry of parameters from the console. 

e SYS1.PARMLIB. This data set is one of the main sources of IPL-time 
parameters. 

e The JES2 or JES3 initialization data set. 


There are several general types of IPL: 


@ The first IPL after sysgen. This is a “cold” start for NIP. 

e Any IPL at which the LPA is reloaded. From the NIP viewpoint this is a 
“cold” start. 

e@ An IPL after power-up (“quick”’ start). 

@ An IPL after a system crash (““warm” start). 


Operator Entry of Parameters: The operator responds to NIP’s SPECIFY 
SYSTEM PARAMETERS message after he IPLs the system. His response directs 
NIP, Master Scheduler Initialization, and other components to the desired parmlib 
members. The operator can enter either ENTER or END* to default to the basic 
general parameter list IEASYSOO, or enter SYSP=(aa,bb. . .) to select one or more 
alternate general parameter lists, such as IEASYSO1, IEASYSO2, etc. The alternate 
lists can supplement or partially override the basic list. The operator need not enter 
parameter values directly, except for those cases in which parameters are missing, 
are syntactically invalid, can’t be read, or must be supplemented to satisfy a special 
case. (An example of a special case would be the operator entry of the PAGE 
parameter to increase the amount of paging space on direct access.) 


*ENTER is used with the Model 158, END with the Model 168. 
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If an error occurs with certain parmlib members, the operator is prompted to 
manually enter one or more of the member’s parameters. If the operator can’t J 
correct a parameter, he can use ENTER or END on the console. ENTER or END 
causes selection of system defaults if they exist. Most parameters have defaults, 
either as default parmlib members, or as coded values in system components. 

If a default doesn’t exist, ENTER or END cancels the parameter. (The defaults 
are listed in the individual descriptions of parmlib members later in Part 2, System 
Initialization.) 


An operator-entered parameter overrides the same parameter specified in parmlib 
member IEASYSOO or IEASYSxx, except for: 


e A parameter in which operator intervention is prohibited (OPI=NO). In this 
case, the operator-entered parameter is ignored unless the parmlib parameter 
was invalid. 


e The PAGE parameter. The page data-set names entered by the operator are 
added for the life of the IPL to those specified in either IEASYSOO or 
IEASYSxx. (For information on the PAGE parameter, refer to the description 
of member IEASYSxx in Part 2.) 


The Use of SYS1.PARMLIB: SYS1.PARMLIB is read by NIP and Master 
Scheduler Initialization at IPL, and later by such components as the System 
Resource Manager, the TIOC, GTF, and MF/1, which are invoked by operator 
command.* The purpose of parmlib is to provide many initialization parameters in 
a prespecified form in a single data set, and thus minimize the need for operator 
entry of parameters. 


Parmlib contains both a basic or default general parameter list, IEASYSOO, 
and possible alternate general parameter lists, called IEASYSaa, IEASYSbb, etc. wi) 
Parmlib also contains specialized members, such as COMMNDxx, PARMTZ, 

IEALPAxx. The general parameter list(s) contain both parameter values and 
“directors”. The directors (e.g., MLPA=01) point or direct NIP or Master 
Scheduler Initialization to one or more specialized members, such ‘as IEALPAQ1. 


* The TIOC is the Terminal I/O Coordinator, whose parameters are described 
under member IKJPRMOO. GTF is the Generalized Trace Facility, whose 
parameters are described under member GTFPARM. Lastly, MF/1 is the System 
Activity Measurement Facility, which is described in Part 4, “How to Use the 
System Activity Measurement Facility (MF/1)”. » 
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System Tailoring Through Operator Commands: After IPL, several operator 
commands provide additional system tailoring by directing particular groups of 
parameters to specific system components. The commands consist of: 


Stop and start JES2 ($p JES2 and $S) 
START tcamproc 

MODIFY tcamproc 

SET IPS 

SETDMN 

START GTF 

START MF1 

START vtamproc 


The System Resources Manager 


To a large degree, the control which an installation exerts over the functioning of 
the MVS system is exercised through the mechanism of the System Resources 
Manager (SRM). Part 3 describes the functioning of the SRM, the parameters 
which control its functioning, and guidelines for defining these SRM parameters. 


The system resources manager (SRM) is a component in the MVS control 


program. The SRM has two principal objectives: 


First, to distribute the system’s processing resources among individual address 
spaces in a way that satisfies the installation’s response and turnaround time 
objectives. 


Second, to attempt to optimize the use of the system’s CPU, storage and I/O 
resources by system users (address spaces). This is primarily a system through- 
put consideration. 


The SRM uses four types of control to accomplish these objectives: 
Domain Control 

Workload Control 

Dispatching Priority Control 

Throughput Control. 


These controls are implemented by combinations of the following seven 


functions: 


Swapping 

Dispatching Priority Control 
Resource Use Functions 
Enqueue Delay Minimization 
Device Allocation 

Prevention of Storage Shortages 
Pageable Frame Stealing. 
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The System Activity Measurement Facility (MF/1) ) 


The System Activity Measurement Facility (MF/1) is an analysis tool which an 
installation may use to monitor selected areas of system activity, and to obtain 
feedback in the form of SMF records and/or formatted reports. MF/1 permits the 
gathering of information on the following classes of system activity, either 
individually or in combination: 


e CPU activity 
e Channel activity and channel-CPU overlap activity 
e I/O device activity and contention for: 


Unit record devices Communication equipment 
Graphics devices Magnetic tape equipment 
Direct access storage devices Character reader equipment 
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e Paging activity 
e Workload activity 


With MF/1, an installation can monitor the utilization of individual CPU’s, 
channels and devices, in order to identify system components whose overall 
utilization is exceptional. The installation can further identify periods of system 
activity during which the utilization of particular resources is exceptional. Finally, 
the installation can relate the service being provided to different classes of users to 
the specifications provided in the Installation Performance Specification (IPS). 


MF/1 is a software monitoring tool. Thus it is limited to reporting on system 
activity as that activity is communicated to the system (for example, by the setting 
of flags). Asa result of this indirect reporting, MF/1 can approach in accuracy, in 
its statistically sampled values, only the internal indications of external system 
activity. For example, if a CPU is disabled so that the freeing of a device (device- 
end interruption) cannot be communicated to the system, the device will appear 
busy for a longer period of time than it would if it were measured by a hardware 
measuring instrument. 


MF/1 is always generated with the system, but its operation is completely 
optional. The system operator initiates MF/1 monitoring with the START 
command. MF/1 can also be started as a batch job. When MF/1 is not operating, 
it will cause little performance or storage overhead. When MF’/1 is operating, the 
storage and performance overhead depend on the set of options that were specified. 


In an installation using the Mass Storage System (MSS), Mass Storage System 
Trace Report programs are used to monitor the MSS. These programs are described 
in OS/VS Mass Storage System (MSS) Services for Space Management. 


System Performance Factors 


Part 5 contains discussions of factors that affect system performance and discussions 
of certain tools that can measure performance. Each discussion includes guidelines 
and rationale. Some discussions also include questions and answers. Since MVS is 
significantly different from MVT, the discussions emphasize new aspects of the 
system, such as VIO, VSAM catalog, and the pageable link pack area. The perfor- 
mance information is based on design analysis; that is, on projections of how the 
system is supposed to work. Some of these ideas will change as system experience is 
gained. 


The following performance topics are included in Part 5, in this order: 


The Pageable Link Pack Area: Its Advantages and Uses 
VIO Performance 

Device Allocation Performance 

VSAM Catalog Performance 

How SMF Can Supplement MF/1 

The Use of GTF to Track Sysevents 

TCAM Tuning Considerations 

Miscellaneous Performance Guidelines 
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Part 2: System Initialization 


This part of the book contains two sections: 


e An overview of initialization 
@ Parmlib member descriptions 
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Initialization Overview 


System Initialization is the part of system tailoring that takes place after sysgen. 
The tailoring results from the specification of system parameters, first at IPL and 
then later when certain operator commands are issued. 


System Tailoring 


System tailoring is the overall process by which an installation selects its operating 
system. The process consists of the specification of system options through these 
mechanisms: 


e System generation 

e IPL-time selections 

e Certain operator commands after IPL 
e Implicit system parameters 
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System Generation 


System generation involves the specification of particular system options under a 
starter system or driver, before the desired system is available. Some system 

options are specified by means of parameters in sysgen macros, such as CTRLPROG, 
SCHEDULR, or DATASET. Some of the CTRLPROG, DATASET and SCHEDULR 
options become the initial contents of certain members of SYS1 PARMLIB, such as 
TEASYS00, IEAAPFOO, and IEAAPPOO. Other members of parmlib (IEAABDOO, 
TEADMP00, IEABLDOO, LNKLSTO0, and IEAPAKO0O) are copied directly from 

the APARMLIB data set to SYS1 .PARMLIB. The initial contents of these members, 
although not determined.by the system programmer at sysgen, can later be altered 
or enlarged through the use of the IEBUPDTE utility. (See Figure 2-3 for the com- 
plete list of members created and copied at sysgen.) 


System Tailoring at IPL Time 


IPL-time choices that help to tailor the system can come from several sources: 


Various types of IPLs. 

Operator entry of parameters from the console. 

e SYS1.PARMLIB. This data set is one of the main sources of IPL-time 
parameters. 

The JES2 initialization data set or JES3 initialization deck. 

e Alternate nucleus selection. 
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Types of IPL 


There are several general types of IPL: 


e The first IPL after sysgen. This is a “cold” start for NIP. 

e Any IPL at which the LPA is reloaded. From the NIP viewpoint this is a 
“cold” start. 

e An IPL after power-up (“quick”’ start). 

e An IPL after a system crash (“warm” start). 


The First IPL After Sysgen: At the first IPL after sysgen, NIP automatically loads 
the LPA from SYS1.LPALIB. The page data sets for this IPL are those named in 
parmlib member IEASYSO0 (built at sysgen), plus any specified by the operator. 
These page data sets are those which were specified in sysgen DATASET macros 
that contained the PAGEDSN keyword or the DUPLEXDS,NAME keyword com- 
bination. The operator need not enter the CLPA (create link pack area) parameter 
in order to load the LPA, since at this first IPL the NIP program will do this auto- 
matically. However, he should enter FORMAT (meaning cold start) as a response 
to the SPECIFY OPTIONS message, since no job queues exist yet on the spool data 
set. 


An IPL at Which the LPA Is Reloaded: The LPA need be loaded only at two times: 
at the first IPL after sysgen, when NIP loads it automatically, and at an IPL after 
the installation has added or modified one or more modules in SYS1.LPALIB, has 
tested the alteration, and now wants to put the replacement module(s) in the LPA. 
To reload the LPA from LPALIB, the operator would enter CLPA (create link pack 
area) as one of his responses to the SPECIFY SYSTEM PARAMETERS message. 
Such reloading of the LPA should not be a common occurrence. It should be done 
only when necessary, since the associated I/O slows down the IPL and because 
previously existing VIO data sets are deleted. (For further information on the load- 
ing of the LPA, see the CLPA parameter in the description of the IEASYSxx 
parmlib member, and the topic “The Pageable Link Pack Area: Its Advantages 

and Uses” in the System Performance Factors chapter.) 


An IPL After Power-Up: The IPL after power-up can be called a “quick start”, 
since the LPA from the previous IPL can be used without reloading from LPALIB. 
Furthermore, VIO data sets can be purged, page data sets added, and swap data sets 
replaced. VIO data sets retained from the previous work shift can be purged, if the 
installation wishes, by the use of the CVIO (clear VIO) parameter. The operator, or 
a general parameter list of parmlib, can add additional page data sets by specifying 
the PAGE parameter and can replace swap data sets by specifying the SWAP 
parameter. (For information on the CVIO and PAGE parameters, see the descrip- 
tion of the IEASYSxx parmlib member later in this chapter.) 


An IPL After a System Crash: After a system crash the operator can “warm start” 
the system by entering or defaulting to the WARM parameter as a response to the 
SPECIFY OPTIONS message. Existing VIO data sets can be retained by the Auxili- 
ary Storage Manager for continued use. Therefore, neither the operator nor his 
specified parmlib parameter list (IEASYSxx) would include the CVIO (Clear VIO) 
parameter. (The specification of one or more IEASYSxx members by the operator 
at IPL time is described in the next topic, “Operator Entry of Parameters’’.) 


Note: See OS/VS2 System Programming Library: Supervisor for information on 
the Power Warning Feature (PWF) pre-IPL options following a power disturbance. 
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Operator Entry of Parameters 


The operator responds to NIP’s SPECIFY SYSTEM PARAMETERS message after 
he causes IPL. His response directs NIP, Master Scheduler Initialization, and 

other components to the desired parmlib members. The operator can enter either 
ENTER or END* to default to the basic general parameter list IEASYSOO, or enter 
SYSP=(aa,bb...) to select one or more alternate general parameter lists, such as 
IEASYSO1, IEASYSO2, etc. The alternate lists can supplement or partially override 
the basic list. The operator need not enter parameter values directly, except for 
those cases in which parameters are missing, are syntactically invalid, can’t be read, 
or must be supplemented to satisfy a special case. (An example of a special case 
would be the operator entry of the PAGE parameter to increase the amount of 
paging space on direct access.) 


If an error occurs with certain parmlib members, the operator is prompted to 
manually enter one or more of the member’s parameters. (Figure 2-4 later in this 
overview lists the parmlib members that prompt for replacement of invalid or miss- 
ing parameters.) If the operator can’t correct a parameter, he can use ENTER or 
END on the console. ENTER or END causes selection of system defaults if they 
exist. Most parameters have defaults, either as default parmlib members, or as 
coded values in system components. If a default doesn’t exist (and if a parameter 
is not required), ENTER or END cancels the parameter. (The defaults are listed in 
the individual descriptions of parmlib members later in this chapter.) 


An operator-entered parameter overrides the same parameter specified in parmlib 
member IEASYSOO or IEASYSxx, except for: 


e A parameter in which operator intervention is prohibited (OPI=NO). In this 
case, the operator-entered parameter is ignored (unless the parmlib parameter 
was syntactically invalid and is being corrected from the console). 

e The PAGE parameter. The page data-set names entered by the operator are 
added for the life of the IPL to those specified in either IEASYSOO or 
IEASYSxx. (For information on the PAGE parameter, refer to the description 
of member IEASYSxx later in this chapter.) 





*ENTER is used with the Model 158, END with the Model 168. 
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The Use of SYS1.PARMLIB 


SYS1.PARMLIB is ready by NIP and Master Scheduler Initialization at IPL, and J 
later by such components as the System Resource Manager, the TIOC, GTF, and 

MF/1, which are invoked by operator command.* The purpose of parmlib is to 

provide many initialization parameters in a prespecified form in a single data set, 

and thus minimize the need for operator entry of parameters. 


Parmlib contains both a basic or default general parameter list IEASYSOO and 
possible alternate general parameter lists, called IEASYSaa, IEASYSbb, etc. 
Parmlib also contains specialized members, such as COMMNDxx, PARMTZ, 
IEALPAxx. The general parameter list(s) contain both parameter values and 
“directors”. The directors (e.g., MLPA=01) point or direct NIP or Master Scheduler 
Initialization to one or more specialized members, such as IEALPAO1. 


Member IEASYSOO, the default general parameter list, is always read but its 
contents can be overridden and/or augmented by the alternate general parameter 
list(s). IEASYSOO can be further supplemented and/or partially overridden by 
operator-entered parameters. The IEASYSxx-lists are selected by the operator 
through the SYSP parameter at IPL. The specialized members can be named by the 
general parameter lists (IEASYSOO and IEASYSxx), or named by the operator at 
IPL. To IPL only with IEASYSO0 and with the specialized lists it names, the opera- 
tor would enter END or ENTER instead of SYSP=xx. 


If the same parameter appears in both IEASYSOO and a specified alternate 
IEASYSxx list, the value in the alternate list overrides. In addition, a parameter 
value in a later specified IEASYSxx list overrides the same parameter in an earlier 
specified list. For example, assume that the operator enters ROO, ‘SYSP=(01,02)’ ~wngil 
in order to select the two parameter lists IEASYSO1 and IEASYSO2. Further assume 
that these two lists and IEASYSOO contain these values: 


IEASYSOO: ... ,MLPA=00,BLDL=00, ... 
IEASYSO1: ... ,MLPA=(01,02) ,BLDL=01,... 
IEASYSO2: ...,MLPA=03,SQA=10,... 


From the above values, NIP accepts: MLPA=03,BLDL=01,SQA=10. 


If a particular parameter or member is unavailable or incorrect, one of the 
following results takes place, depending on the particular member: 


e A default value is used, or 

e Processing of the parameter or the rest of the member is bypassed, or 

e The operator is prompted to enter replacements for the invalid parameter(s), 
or to enter all the parameters in the member or to re-IPL, or to cancel 
the parameter or member by entering END or ENTER. 


The handling of each member at a syntax error or read error is listed later in this 
overview in Figure 2-2. 


*The TIOC is the Terminal I/O Coordinator, whose parameters are described under 
member IKJPRMOO. GTF is the Generalized Trace Facility, whose parameters are 
described under member GTFPARM. Lastly, MF/1 is the System Activity Measure- 
ment Facility, which is described in Part 4, ““How to Use the System Activity <i 
Measurement Facility (MF/1)”’. 
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How Parmlib Menibers Are Created: Parmlib members are created in several ways: 


e@ Some are unconditionally created at sysgen by being copied from the 
APARMLIB data set. They may later be changed or augmented by the instal- 
lation through the use of the IEBUPDTE utility. 

e@ Others are conditionally created at sysgen, if particular sysgen macros and 
keywords are specified. 

e The remaining members can be explicitly created by the installation. 


Figure 2-1 shows which parmlib members are created at sysgen, whether the 
creations are conditional, the names of any associated sysgen macros and keywords, 
and the IPL-time parameters that direct the reading system components to the 
desired specialized members. (See notes at bottom of figure.) 


Associated IPL- Time 

Parameter (in 

IEASYSOO, IEASYSx~x, 

or entered by the Initially Built Sysgen Macro 
Operator) at Sysgen and Parameter 


COMMNDxx no 
GTFPARM no 


IEAABDOO yes: default list 
is copied from 
APARMLIB. 


IEAAPFOO conditionally, if sysgen CRTLPROG 
macro is specified APFLIB= 


1IEAAPFxx no N/A 


\EAAPPOO conditionally, if sysgen DATASET 
macro is specified. ABEAPP= 
CHEAPP= 
EOEAPP= 
PCIAPP= 
SIOAPP= 


1EABLDOO yes: default list is copied CTRLPROG 
from APARMLIB, aug- OPTIONS= 
mented via sysgen macro BLDL 
if it is specified. 


IEABLDxx no N/A 


1EADMPO0O yes: default list is N/A 
copied from APARMLIB. 


IEAFI X00 DATASET 
conditionally, if sysgen RESIDNT= 
macro is specified. 


IEAFIXxx 


Notes: 
1. Ano” in the third column means the member is installation-created. 


2. N/A means “not applicable”. 





Figure 2-1. Parmlib Members: Relationships to IPL Parameters and Sysgen Parameters (Part 1 of 2) 
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Member 


IEAIPSOO 


IEAIPSxx 


lEALODOO 


TEALPAxx 


IEAOPTOO 


IEAOPTxx 


IEAPAKOO 


IEASYSOO 


1EASYSxx 


IKJPRMOO 


IRBMF 100 


IRBMF1xx 


LNKLSTOO 


LNKLSTxx 


MVIKEYOO 


PARMTZ 


SMFPRMOO 


SM FPRMxx 


VATLST=xx 


Associated IPL-Time 
Parameter (in 
IEASYSOO, IEASYSxx, 
or entered by the 
Operator) 


IPS-00 


IPS=xx 
None 
MLPA=xx 
OPT=00 
OPT=xx 


none, although member is used 
only when CLPA is specified. 


SYSP=xx, issued by the 
operator 


none 


none 


Initially Built 
at Sysgen 


yes: default list is copied 
from APARMLIB. 


no 

no 

no 

no 

no 

yes: default list is copied 
from APARMLIB, optionally 
augmented or altered by 


installation before IPL. 


yes, if sysgen macros 
are specified. 


no 


no 


yes: default list is copied 
from APARMLIB. 


no 


yes: default list is copied 
from APARMLIB. 


no 


yes: default list is copied 
from APARM LIB. 


no, although time zone 
constant can be specified by the 
TZ keyword of CTRLPROG 
macro and placed in the CVT. 
yes 


no 


no 





Figure 2-1. Parmlib Members: Relationships to IPL Parameters and Sysgen Parameters (Part 2 of 2) 


Sysgen Macro 
and Parameter 


(see Figure 2-11 
in |EASYSxx) 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


N/A 


Overview of Parmlib Members: Figure 2-2 lists all the parmlib members that are 
valid in MVS. The table briefly describes the purpose of each member, indicates 
whether the member was introduced in MVT, VS2 Release 1, or MVS, and lists 
additional categories of information for each of the parmlib members. 
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How to Control Parmlib: To control parmlib and assure that it is managable, you 
should consider the following problem areas and suggested solutions: 


@ Delete unsupported parameters and members. Since most components treat 


unsupported parameters from previous releases as syntax errors, you should 
probably remove the old parameters or build parmlib from scratch. This 
action will minimize the need for operator responses during an IPL. Further- 
more, you can save space by removing unsupported members. Figure 2-2 
shows which old members are not supported in MVS, and which changed 
members can involve unsupported parameters. 


Update parmlib with new and replacement members, as you gain familiarity 
with the new release. You can use the IEBUPDTE utility to add or replace 
members. Figure 2-3 illustrates the JCL for adding three new members and 
replacing two old members: IEABLDOO, IEALODOO, IEAPAKOO, IEASYSOS, 
and IEASYSO06. (Consult the OS/VS Utilities manual for further information 
on the use of IEBUPDTE.) To prevent excessive growth of parmlib, use the 
“compress” function of IEBCOPY to delete obselete data. 


//ADDLISTS JOB 61938, 'R.L. WILSON’ 

/ISTEP EXEC PGM=IEBUPDTE, PARM=MOD 
/ISYSPRINT DD SYSOUT=A 

IISYSUT1 DD DSNAME=SYS1.PARMLIB, DISP=OLD 
IISYSUT2 DD DSNAME=SYS1.PARMLIB, DISP=OLD 
/ISYSIN DD DATA 


f 
/ 


/ 
/* 


ADD NAME=IEABLDOO, LIST=ALL 
NUMBER NEW1=01, INCR=02 


SYS1.LINKLIB IEFSD061, IEFSD062, IEFSD064, IEFSD104, 


IEFVM1, IEF WCOOO, IEFWDOOO, IEFW21SD, 
IEFW41SD, IEFW42SD, IEFXJO00 

REPL NAME=IEALODOO, LEVEL=01, SOURCE=1, 
LIST=ALL 

NUMBER NEW1=10, INCR=100 

IEFAB400, IGG0325A, |GG0325H, |GC0003B, 
1GG0325B, |GGO325D, |GG0325E, 

IGG0325G, IFGO202J, |FGO202K, IFGO202L 
REPL NAME=IEAPAKOO, LEVEL=01, SOURCE=1, LIST=ALL 
NUMBER NEW1=01, INCR=02 

(lIEFAB400, 1GG0325A, |GGO325H, |GC0003B), 
(1GG0325B, |GG0325D, |GGO325E, 
1GGO235G), (IFGO202J, IFGO202K, IFGO202L) 
ADD NAME=IEASYS05, LIST=ALL 

NUMBER NEW1=01, INCR=02 

MLPA=(00, 01), 

BLDL=00, SQA=2 

ADD NAME=IEASYS0O6, LIST=ALL 
NUMBER NEW=01, INCR=02 

MLPA=(02, 03), BLDLF=(00, 01), 

SQA=1, FIX=(00, 01), OPI=NO 

ENDUP 


Note: This example shows the format of IEBUPDTE statements, not the content of 
parmlib members. 


Figure 2-3, Example of Adding and Replacing Parmlib Members by Means of the IEBUPDTE 


Utility 
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and DATASET macros) and which parameters are included in particular 
parmlib members. This bookkeeping is necessary for two reasons: 1. The 
system doesn’t keep track of parmlib members and their parameters. 2. The 
default general parameter list IEASYSOO is always read by NIP and Master 
Scheduler Initialization. The list’s parameters can be overridden by the same 
parameters when they are specified in alternate general lists, such as 
IEASYSO1, IEASYSO2, etc. Furthermore, certain parameters, such as FIX, 
APF, and MLPA, direct the system to particular specialized members (in this 
example, IEAFIXxx, IEAAPFxx, and IEALPAxx). The installation should 
keep records of which parameters and which values are in particular members, 
and which general members point to which particular specialized members 
(COMMNDxx, IEALPAxx, etc.) A grid or matrix for such bookkeeping is very 
helpful. 


e@ Keep track of which parameters were specified at sysgen (through CTRLPROG 


e Allocate sufficient space for parmlib. The space must be a single extent. One 
way to estimate space is to count the number of characters, including blanks, 
(by counting 80-character records) in all members. Then add a suitable growth 
factor (e.g., 100—300%) to allow for future growth of alternate members. 
Consult Figure 2-2 to determine which members can have multiple alternates. 
To recapture space from obselete members, use the ‘“‘compress” function of 
IEBCOPY. 


Note: It is better not to let members cross cylinder boundaries because some 
members are used during IPL. Those that are will generate I/O errors during 
IPL if they cross cylinder boundaries. 


@ Decide the volume and device that should hold parmlib. The volume could be 
demountable, although it must be mounted in order for the operator to start 
GTF, to start MF/1 as supplied with the system, to start time sharing by use J 
of the MODIFY tcamproc command, or to try to specify a new installation . 
performance specification by use of the SET IPS command. The volume must 
be cataloged, unless it is SYSRES. It could be placed on a slow or moderate 
speed device. 


e@ Password protect the data set. Parmlib should be password protected for 
“write”. The purpose is to shield the appendage member (IEAAPPOO) and the 
Authorized Program Facility member (IEAAPFxx) from user tampering. 
Member IEAAPPO0 is particularly sensitive, since a user could add an appendage 
that would give his routine control in zero protection key and supervisor state. 


General Syntax Rules for the Creation of Members: The following general syntax 
rules apply to the creation of most parmlib members. Exception to these rules are 
described under specific members later in this chapter. The general rules are: 


Record size is 80 bytes. 

Any columns between 1 and 71 may contain data. 

Columns 72 and 80 are ignored. 

Continuation is indicated by a comma followed by one or more blanks after 
the last entry on a record. 


e@ Leading blanks are suppressed. A record therefore need not start at a particular 
column. 

e Suffix member identifiers (such as LNK=A2) can be any alphameric 
combination. 
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Causing an Alternate Nucleus Substitution 


Another less common way to change the system at an IPL is to cause the IPL 
program to read a member of a nucleus data set that is different from IEANUCO1, 
the default nucleus member. One reason for such a nucleus switch may be the need 
to apply a PTF. The operator process to cause the switch is described under “Load-. 
ing a Secondary Nucleus” in the Operator’s Library: OS/VS2 Reference (JES2). 


System Tailoring Through Operator Commands 


After IPL, several operator commands provide additional system tailoring by 
directing particular groups of parameters to specific system components. The 
commands consist of: 


START tcamproc 
MODIFY tcamproc 
SET IPS 

SETDMN 

START GTF 
START MF1 
START vtamproc 


Starting TCAM 


The operator can enter TCAM initialization parameters when he starts TCAM, as a 
response to the SPECIFY TCAM PARAMETERS message. TCAM issues the message 
if the system programmer accidentally or deliberately omitted one or more required 
parameters when he coded the INTRO macro for TCAM assembly. In response to the 
message, the operator can add to or modify existing TCAM parameters. (For 
information on the TCAM parameters, refer toOS/VS2 TCAM Programmers Guide. ) 


Starting VTAM 


VTAM start options can be entered by the network operator as parameters in the 
START command or they can be specified in a start option list. The start option list 
is stored in SYS1.VTAMLST and is specified by the LIST parameter in the START 
command. For information about VTAM initialization, refer to OS/VS2 System 
Programming Library: VTAM. 
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Starting Time Sharing 


The operator starts TCAM, then issues the following command in MVS in order to 
start time sharing: 


MODIFY tcamproc, TS=START [,membername] 


The optional parameter membername can specify an installation-defined parmlib 
member, or can default to the parmlib member IKJPRMOO. In either case, the 
member is ready by the Terminal I/O Coordinator (TIOC). The TIOC uses the 
parameters mainly to control time-sharing buffers. (For additional information on 
TIOC parameters, see the description of member IKJPRMO0 later in this chapter.) 


Using SET IPS to Change System Resources Manager Parameters 


The SET IPS command causes the system resources manager to receive a specific 
installation performance specification (IPS). This IPS is a parmlib member 
(IEAIPSxx). By use of this command, the installation can dynamically change 

IPS parameters between IPLs. (For further information, refer to the IPS parameter 
in the description of the IEASYSxx member, and in the chapter entitled “The 
System Resources Manager’’.) 


Using SETDMN to Change Domain Constraints 
The SETDMN command provides a way for altering the constraint values on a ) 


domain’s multiprogramming level. The information from this command is valid 
only for the life of the IPL — it does not change fields in the IPS member. 
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Starting GTF 


When the operator starts the Generalized Trace Facility (GTF), the parameters are 
obtained from the PARM field of the START command and from a parmlib member. 
If the operator issues START GTF, the IBM-supplied cataloged procedure (named 
GTF) is read. The PROC statement of that procedure names GIFPARM as the 
member from which GTF will get its parameters. If, however, the installation wants 
to substitute another member in place of GTFPARM, the operator may enter the 
alternate member name with the MEMBER keyword of the START command. (For 
further information on GTF initialization parameters, see the description of member 
GTFPARM later in this chapter. For other information on starting or using GTF, 
refer to the GTF chapter in OS/VS2 System Programming Library: Service Aids. ) 


Starting MF/1 


The System Activities Measurement Facility (MF/1) is started by means of the 
START procname command. Parameters to control measurements, reports, and 
SMF records are taken from a merge of three sources, in this order: 


1. PARM field of the START command 
2. PARM field of the EXEC statement in the proc named by the command 
3. MF/1 partitioned dataset member (typically the IRBMF1xx member of parmlib) 


If the IBM-supplied procedure (named MF 1) is specified in the command, the 
MF/1 partitioned data set is SYS1.PARMLIB. The MF/1 member names must always 
be of the form IRBMF1xx. The default member IRBMF100 is supplied by IBM. 
(For further information on MF/1, its uses and parameters, see the part of this book 
entitled ‘How to Use the System Activity Measurement Facility (MF/1.”’) 


Implicit System Parameters 


Various system requirements, although not involving explicit parameters, affect the 
way the system performs. These system requirements may be considered as “implicit” 
parameters. They involve dd statements, data sets, hardware choices, etc. Some 
examples are: 


e SYSABEND and SYSUDUMP dd statements. Without these statements, the 
parameters in parmlib members IEAABDOO and IEADMP00 and the dump 
option lists in ABEND macro instructions are useless, since an ABEND dump 
cannot be taken. 


e@ SYSMANX and SYSMANY data sets must be allocated on direct access 
volumes and be cataloged. If this condition is not met, the Master Scheduler 
fails during IPL. This may be considered an implicit SMF parameter. 


e Addition of new modules to SYS1.LPALIB through use of IEBCOPY or the 
Linkage Editor. This affects the size and usefulness of the LPA that is loaded 
by specification of the CLPA parameter at IPL. 


e@ Choice of the device on which the LPA paging data sets will reside. This choice 


affects the speed at which LPA modules can be paged into real storage and thus 
system performance. 
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| e Definition of page data sets by means of the DEFINE PAGESPACE 
command. The PAGE parameter, issued at IPL through parmlib and/or the J 
operator, is meaningful only if the specified data sets have been previously 

| formatted by the DEFINE PAGESPACE command. (See OS/VS2 Access 
Method Services for information on this command.) 


Warning: NIP enforces a uniprocessor IPL when a system that has been generated 
without MP modules tries to initialize on MP or half duplex. The operator at IPL 
must ensure that at least 768K bytes of contiguous storage are dialed online, if the 
system was generated with ACRCODE=NO in the CTRLPROG macro. If the storage 
Tequirement is not met, NIP issues a message and may cause a wait state. 
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C Descriptions of Individual PARMLIB Members 


The individual parmlib members, listed in alphabetic order, are described in the 
following topics. 


Member Name: COMMNDxx 
Status: New for VS2 Release 2 


Use of the Member 


COMMNDxx is an optional installation-created list of automatic commands to be 
internally issued by the system as part of Master Scheduler Initialization. 
COMMNDxx is useful for automatic entry of commands, such as START MF/1, that 
may be frequently issued at System Initialization. The member cannot be used to 
issue JES2 commands, since COMMNDxx commands are issued before JES2 is 
started. COMMNDxx also contains the TOD keyword. This keyword indicates 
whether messages from TOD Clock Initialization should be issued to prompt the 
operator. The installation can use this keyword to speed up the initialization pro- 
cess, if it feels that these messages are unnecessary. (See the NOPROMPT operand 
of the TOD keyword.) 


The TRACE ON command may be placed in a COMMNDxx member, if OS Trace 
is desired after NIP processing (to cover log initialization, startup of GTF, and the 
latter part of JES2 initialization). OS Trace is turned off during GTF operation if 

Pa TRACE ON was requested at IPL. TRACE OFF may be requested at the next IPL 
by operator command (before responding to the JES2 SPECIFY OPTIONS 
message), or via another COMMNDxx member. 


Caution: The use of TRACE ON should not be encouraged, because it degrades 
the system and because it can’t be stopped until] the next IPL. 


The following commands should not be put in COMMNDxx because they are 
console-oriented. They should be issued only on the console for which they apply: 


Command Abbreviation 
CONTROL K 
MSGRT MR 
TRACK TR 
STOPTR PT 


Warning: Do not place JES2 commands in COMMNDxx, since JES2 is not 
started until after the COMMNDxx entries have been processed. 


The default member COMMNDOO, if it exists, is read if CMD=xx is not included 
in the system parameter list (IEASYSxx) or is not specified by the operator. If 
Initialization can’t find either the specified COMMNDxx member or COMMNDOO, 
processing continues without provision for automatic commands. 
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COMMNDxx (continued) 


Parameter in IEASYSxx: 


as : = aa 
(or issued by the operator) CMD baat i Q 


The two-character identifier (aa, bb, etc.) is appended to COMMND to identify the 
COMMNDxx member(s) of parmlib. Multiple members can be specified. 


Note: Commands issued from COMMNDxx do not show on the console. Therefore, 
the results of these commands appear on the console without the operator’s seeing 
the command. 


Syntax Rules 


The following rules apply to the creation of COMMNDxx by means of the 
IEBUPDTE utility: 


e Enter only one command per card image. Enter the COM= keyword, followed 
by the command enclosed in apostrophes. For example, to start TCAM through 
use of the IBM-supplied PROC, enter COM=‘s TCAM’. 

e Specify the TOD=keyword on a single card image. For example, TOD= 
PROMPT (This entry will cause prompting messages during TOD clock 
initialization.) 

e Do not specify continuation on any card image. 


IBM-Supplied Defaults: None 


Internal Parameters 


Default 
Parameter Meaning Value 
COM=‘command name’ The specified command No commands 
will be issued by the will be issued. 
system during Master 
Scheduler Initialization. 
eae 
~ (NOPROMPT Messages will (will not) NOPROMPT 
be issued to the operator 
during TOD clock 
initialization 
If NOPROMPT is specified, 


the system will prompt the 
operator to set the TOD 
clock only if the clock is 
not set, or in a multipro- 
cessing system, if the TOD 
clocks are not synchronized. 
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Member Name: GIFPARM (or an installation-supplied name) 
Status: New for VS2 Release 2 


Use of the Member 


GTFPARM provides default or installation-defined trace options to control the 
Generalized Trace Facility (GTF). The member is read only when the operator (or an 
automatic command) issues START GTF. It is not used during System Initialization. 
(For use of the TRACE command to continue or discontinue OS Trace after IPL, 
see Operator’s Library: VS2 Reference (JES2).) 


The procname of the START command can name an IBM-supplied cataloged 
procedure. The PROC statement of that procedure identifies GTFPARM as the 
member from which GTF will get its trace parameters. If the installation wants to 
substitute another member in place of GTFPARM, the operator may enter the 
replacement member name on the START command with the MEMBER keyword. 


The IBM procedure, as supplied in SYS1.PROCLIB, contains these statements: 


//GTF PROC MEMBER=GTFPARM 

/NEFPROC EXEC PGM=AHLGTF,PARM=’MODE=EXT,DEBUG=NO, 
TIME=NO’ 

/NEFRDER DD DSNAME=SYS1.TRACE,UNIT=SYSDA, 

// SPACE=(4095,20),DISP=(NEW,KEEP) 

//ISYSLIB DD DSN=SYS1.PARMLIB(&MEMBER),DISP=SHR 


For further analysis of this procedure, refer to the GTF chapter of OS/VS2 System 
Programming Library: Service Aids. 


Since default options in GIFPARM specify minimal data for only a limited 
number of traced events, you may wish to expand GTF: capabilities through one of 
the following methods: 


e Specify another member name via the MEMBER keyword on the START 
command. 


@ Change the trace options in GTFPARM, by using the IEBUPDTE utility. 


e@ Change the SYSLIB DD statement of the IBM procedure, in order to specify a 
different option list, which you create via IEBUPDTE. 


e Retain the IBM procedure to handle default options, and write one or more 
alternate procedures, each specifying a different alternate parmlib member. 
You could design each member to contain GTF options useful under par- 
ticular circumstances. Instruct the operator when to issue the START 
command for each procname. 


GTF tries to read parameters from the specified parmlib member. If an error 
occurs in opening or reading the member, or if GTF detects a syntax error, it 
writes a diagnostic message to the operator, and requests him to SPECIFY TRACE 
OPTIONS, as if no GTF parmlib member were available. The operator therefore 
must have a complete list of desired GTF parameters available when he starts the 
facility. 
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GTFPARM (continued) ) 


Parameter in IEASYSxx: None 
(or issued by the operator) 


Syntax Rules: 


The following rules apply to the creation of a GIF parmlib member by means of 
the IEBUPDTE utility: 


e@ Specify the TRACE keyword and its main options only on the first record. 
Do not place them on subsequent records. For example, 


Record #1: TRACE=IOP,SVCP,SIO 


This example requests the tracing of specific I/O interrupts, specific SVC 
interrupts, and all Start I/O operations. 


e The second and subsequent records should contain only “prompting” key- 
words, such as IO= or SVC=. These keywords provide for detailed operands 
that indicate which I/O interrupts or which SVC interrupts should be traced. 
For example, the IOP and SVCP keywords in the Record # 1 example (above) 
must be followed by prompting records that name specific unit addresses 
and specific SVC numbers for which interrupts should be traced. As an 
example, 


Record # 2: 10=(191,192,193), SVC=(1,2,3) ; | 


If the specific operands of any prompting keyword are missing, GTF does not 
prompt the operator initially. It accepts a general specification. For example, 
if IOP is specified in record # 1, and particular device addresses are not 
specified in a later record, GIF assumes that tracing of I/O interrupts is 
desired for all devices. 


Later, when all records have been read, GTF issues message AHL1031 
TRACE OPTIONS SELECTED — IO (rather than IO=(191,192,193)). The 
operator can then respond to the accompanying message AHL125A 
RESPECIFY TRACE OPTIONS OR REPLY U by entering Rxx,JO=(191,192, 
193) to indicate the devices whose I/O interruptions should be traced. 


e@ An END statement or an end-of-file must follow all prompting keywords. 


e Ifyou need to specify additional operands for the same keyword, restate the 
keyword and the additional operands in a subsequent prompting record. The 
previous examples, expanded to include additional SVC numbers and an END 
keyword, would appear like this: 


Record # 1: TRACE=IOP,SVCP,SIO 
Record # 2: 1O=(191,192,193) SVC=(1,2,3) 
Record # 3: SVC=(4,5,6,7,8,9,10),END 
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GTFPARM (continued) 


e Certain trace options (prompting vs. non-prompting, general vs. specific) are 
mutually exclusive. (See Figure 2-4) Options listed in the same column of the 
table are mutually exclusive. If you select two or more options from the same 
column, the option listed highest in the column will take effect. For example, 
if you specify both SYSP and SIO from the first column, SYSP will take effect 
and SIO will be ignored. 


Note: Options listed in each column are mutually exclusive. 
Preferential order is from top to bottom. 


SYSM SYSM SYSM SYSM SYSM SYSM DSP USR TRC PCI SRM 

SYSP SYSP SYSP SYSP SYSP SYSP 

SYS SYS SYS SYS SYS SYS These parameters are not mutually 
SIOP IOP SVCP PIP EXT RR exclusive with other parameters. 
SIO 10 SVC Pl 





Figure 2-4. Mutually Exclusive Options for GTFPARM 


IBM-Supplied Defaults 


When GTF is started by specifying the IBM-supplied cataloged prccedure, the 
following options exist in GTFPARM: 


TRACE=SYSM,USR,TRC,DSP,PCILSRM 


These keywords will cause the following events to be recorded: SVC interruptions, 
I/O interruptions, PCI interruptions, program interruptions, external interruptions, 
dispatcher executions, Start I/O instructions, entries to the System Resource 
Manager, entries to recovery routines, events associated with GTF (TRC), and data 
passed to GTF via the GTRACE macro (USR). All keywords except USR result in 
minimal format trace entries. USR entries will be the length specified by the user 
in the GTRACE macro. Such entries may optionally be a maximum of 256 bytes, 
excluding the prefix. 


Internal Parameters 


Parameter Meaning and Use 


SYS This parameter requests comprehensive recording for six 
system events: I/O, SIO, SVC, program, external interrup- 
tions, and entry to recovery routines (RR). If any additional 
trace options are coded (e.g., SRM, DSP), trace 
entries for these options will also be comprehensive. 


SYSP This parameter produces results similar to that produced by 
SYS, except that GIF prompts for particular events (e.g., 
address of I/O device or SVC number). As with SYS, if 
any additional trace options are coded, trace entries for 
these options will also be comprehensive. 
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GTFPARM (continued) 


Parameter 


SYSM 


SIO 


SIOP 


IO 


IOP 


SVC 


SVCP 


PI 


PIP 


EXT 


Meaning and Use 


This parameter produces results similar to that for SYS, 
except that minimal trace data are recorded for the six 
events. If any additional trace options are coded (e.g., SRM, 
DSP), trace entries for these options will also be minimal, 
except for USR entries. USR entries are the length specified 
by the user in the GFRACE macro. 


NOTE: Specification of either SYS or SYSM causes the 
following trace options to be ignored if specified, 
since they are included in SYS or SYSM: SIO, IO, 
SVC, PI, EXT,RR. 


This parameter requests comprehensive recording for system 
SIO operations. 


This parameter is similar to SIO except that it requests GTF 
to prompt for the addresses of specific devices (e.g., 151, 
152) for which SIO events should be recorded. Only the 
devices for which the operator replies, or the parmlib 
member specifies, will cause SIO entries in the trace. 


This parameter requests comprehensive recording of all non- 
PCI I/O interruptions. To obtain recording of PCI interrup- 
tions, specify PCI. Both options may be specified. 


This parameter requests the same type of recording as does 
IO, except that GTF prompts for the addresses of specific 
devices whose I/O interruptions will be recorded. 


This parameter requests comprehensive recording of all SVC 
interruptions. 


This parameter is similar to SVC, except that GTF will 
prompt for specific SVC numbers for which data is to be 
recorded. 


This parameter requests comprehensive recording for all 
program interruptions (1—19). 


This parameter is similar to PI except that GIF prompts 
for the specific interruption codes for which data is to be 
recorded. 


This parameter requests comprehensive recording for all 
external interruptions. 


46 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2 Release 3.7) 


GTFPARM (continued) 


Parameter 
RR 


DSP 


PCI 


SRM 


TRC 


USR 


END 


Meaning and Use 


This parameter requests that uses of recovery routines 
(FRRs and STAE/ESTAE routines) be recorded. The trace 
record is created when the recovery routine returns control 
to the Recovery Termination Manager (RTM). Daia is in 
comprehensive format except when the option is specified 
via SYSM. 


This parameter requests recording for the local dispatching 
of units of work (service request block (SRB) and TCB). 
The option is not included in the specification of SYS or 
SYSM. It must be specified in addition to other parameters. 
The parameter produces comprehensive format except when 
SYSM is also specified. With SYSM, data is in minimal 
format. 


This parameter requests that PCI interruptions be recorded 
in the same format as other requested I/O trace records. If 
specific I/O device addresses are specified through prompt- 
ing records, the PCI interruptions will be recorded for the 
same devices. I/O tracing must be requested, since PCI can- 
not be specified without IO. 


This parameter requests a trace entry each time that the 
System Resource Manager (SRM) is invoked. The option 

is not included in the specification of SYS or SYSM. It must 
be specified in addition to other parameters. Data is in 
comprehensive format except when SYSM is also specified. 
Comprehensive format includes the jobname. 


This parameter requests that traced events include those 
related to GTF processing itself. If this parameter is not 
specified, GTF-related events will be excluded from the 
trace output. 


This parameter requests that user data passed to GTF via 
the GTRACE macro be recorded with the system data. 


This parameter indicates the end of the prompting records. 
In the parmlib member an end of file serves the same pur- 
pose. Never include the END parameter in the first record 
(the record that contains the TRACE parameters), since 
GTF regards such occurrence as an error. 
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Member Name: IEAABDO0O — (See also IEADMPO0) 
Status: New for VS2 Release 2 


Use of the Member 


IEAABDOO contains IBM defaults and/or installation assigned parameters for 
ABDUMP, for use when an ABEND dump is written to a SYSABEND data set. 
(For ABDUMP parameters associated with a SYSUDUMP data set, see member 
IEADMPO0.) 


ABDUMP parameters for a dump to be taken to a SYSABEND data set may be 
specified in any of three ways: 


e A parameter list pointed to by the DUMPOPT keyword of an ABEND macro 
instruction.* The list can be built by using the list form of the SNAP macro. 
(See Supervisor Services and Macro Instruction for details regarding the 
ABEND and SNAP macros.) 


e Default options specified in IEAABDOO. These options control the content of 
the ABEND dump if the programmer doesn’t include the DUMPOPT keyword 
and its associated parameter list with his ABEND, CALLRTM, or SETRP 
macro. If the DUMPOPT keyword is included, the specified options are 
merged with those in IEAABDOO. 


@ Temporary override options that an operator can specify with a CHNGDUMP 
command (see cautionary statement below). 


The reader should note that options specified by the CHNGDUMP command are 
distinctly different from those provided by the DUMPOPT list or the IEAABDOO 
options. Either of these lists can provide a reasonable dump, selected either by the 
application programmer or the installation system programmer. The CHNGDUMP 
command, however, must be issued very carefully, in order not to nullify dump 
options. Parameters in a CHNGDUMP command are overriding; that is, they tem- 
porarily replace all dump options specified in both IEAABD0O0 and all ABEND 
macro instructions. Only those parameters specified in CHNGDUMP are effective. 
Parameters not specified in CHNGDUMP are temporarily nullified, even though 
they still exist in IEAABDOO or in ABEND DUMPOPT lists. The overrides prevail 
until the operator issues another CHNGDUMP command, specifying the DEL 
keyword, or until the system is reinitialized (whichever occurs first). 


As an example of how CHNGDUMP can accidentally wipe out desired ABDUMP 
options, assume that IEAABDO0 contains the following options: 


SDATA=(SQA,CB,ENQ),PDATA=(PSW,REGS,SA,ALLPA) 


Further assume that the operator is told to add TRT to the SDATA options, in 
order to dump the trace table, and to add SPLS to the PDATA options in order to 
dump user storage acquired for the failing task. The operator, having only a 
superficial grasp of the command, enters: 


CHNGDUMP SET,SYSABEND,SDATA=(TRT),PDATA=(SPLS) 


*An ABEND dump can also be requested by a CALLRTM or SETRP macro. See 
OS/VS2 System Programming Library: Supervisor. 
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IEAABD00 (continued) 


The operator thinks he has added the TRT and SPLS parameters to an incomplete 
list and that he has expanded the list by two parameters. Actually, the operator has 
set up effectively a new parameter list containing only two parameters: SDAT A= 
TRT and PDATA=SPLS. He has unwittingly overridden and therefore nullified 
SDATA=(SQA,CB,ENQ),PDATA=(PSW,REGS,SA,ALLPA). He has also overridden 
any DUMPOPT parameters specified by programmers for use with their ABEND 
macro instructions. (For syntax information on the CHNGDUMP command refer 
to Operator’s library: VS2 Reference (JES2).) 


The ABDUMP Initialization routine reads IEAABDOO to get ABDUMP param- 
eters. If during Initialization, IEAABDOO is found to be invalid or can’t be located, 
the operator is notified. No prompting occurs. If both valid and invalid options are 
included in the member, or a syntax error is encountered, a message lists the valid 
options that were accepted before the error occurred. 


Parameter in IEASYSxx: None 
(or specified by the operator) 


Syntax Rules 


The following rules apply to the replacement of IEAABDOO by means of the 
IEBUPDTE utility: 


e@ There are two keywords, SDATA and PDATA. Each keyword is followed by a 
string of operands separated by commas and enclosed in parentheses. A single 
operand does not need parentheses. 


Examples: 
SDATA=(SQA,CB,ENQ,TRT) or SDATA=ALLSDATA 
PDATA=(PSW,REGS,SA,ALLPA,SPLS) or PDATA=ALLPDATA 


e Normally both parameters (i.e., SDATA=operands and PDATA=operands) can 
fit on one card image. If, however, continuation is needed, use a comma 
followed by a blank. 


Example: 
SDATA=(SQA,CB,ENQ,TRT), 
PDATA=(PSW,REGS, 
SA,ALLPA,SPLS) 
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IEAABDO0 (continued) 


IBM-Supplied Defaults 

The following defaults are placed in IEAABDOO by IBM: 
SDATA=(LSQA,CB,ENQ,TRT),PDATA=(ALLPA,SPLS) 

These options request a dump of the following areas: 


LSQA, including subpools 229 and 230 

formatted control blocks for the task 

formatted enqueue control blocks for the task 

GTF trace or supervisor incore trace 

(See explanation under TRT parameter) 

e modules listed on the link pack area queue and the job pack area queue, and 
active SVC modules related to the failing task 

@ user storage allocated for the task 


Internal Parameters 


Parameter Meaning and Use 
SDATA= 
ALLSDATA All the following options are automatically specified. 


The following parameters request dump of specific SDATA areas, as indicated: 


NUC Control program nucleus. SQA, LSQA and the PSA are 
included. 

SQA The system queue area. 

LSQA Local system queue area for the address space, including 


subpools 229 and 230. 


SWA Scheduler work area used for the failing task. 

CB Control blocks related to the failing task. 

ENQ Enqueue control blocks (QCBs and QELs) related to the 
failing task. 

TRT GTF or supervisor trace table depending on whether the 


ABEND occurs after or during IPL, and whether the TRACE 
ON command was issued at IPL. If the ABEND occurs during 
NIP or Master Scheduler Initialization, the supervisor trace 

is displayed. Otherwise, the GTF trace is displayed, provided 
that GTF has been started. If GTF is not running, and the 
TRACE ON command was issued at IPL, the Supervisor trace 
table is displayed. (For the use of the TRACE command, see 
Operator’s Library: VS2 Reference (JES2). 
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IEAABD00 (continued) 


Parameter 


PDATA= 


ALLPDATA 


Meaning and Use 


All the following options are automatically specified. 


The following parameters request dump of specific PDATA areas, 


as indicated: 


PSW 


REGS 


SA or SAH 


JPA 


LPA 


ALLPA 


SPLS 


Program status word at entry at ABEND. 


Contents of general registers at entry to ABEND. 


SA requests save area linkage information and a backward 
trace of save areas. This option is automatically selected if 
ALLPDATA is specified. 


SAH requests only save area linkage information. 


Contents of the job pack area (module names and contents) 
that relate to the failing task. 


Contents of the LPA (module names and contents) related 
to the failing task. Includes active SVCs related to the 
failing task. 


Contents of both the job pack area and the LPA, as they 
relate to the failing task, plus SVCs related to the failing 
task. 


User storage subpools (O—127) related to the failing task. 
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Member Name: IEAAPFxx : 
Status: New for VS2 Release 2 


Use of the Member 


IEAAPFxx is a list of program library names (dsnames) and corresponding volume 
serial numbers that require APF authorization. (APF means the Authorized Program 
Facility.) SYS1.LINKLIB and SYS1.SVCLIB are automatically authorized. SYS1. 
LPALIB, however, is not automatically authorized, since it is closed at the end of 
NIP processing and is not required until the next IPL at which time the LPA is to 

be reloaded. 


If an installation wants IEAAPFxx, it must explicity create the member via the 
IEBUPDTE utility. The default member IEAAPFOO, however, may be optionally 
created at sysgen through the use of the APFLIB keyword of the CTRLPROG macro. 


Warning: Be careful when you list a library in IEAAPFOO or IEAAPF xx that is 
concatenated to other libraries. If any of the concatenated libraries is not 
authorized, all the concatenated libraries will become unauthorized when they 
are opened. 


Parameter in IEASYSxx: APF=xx 
(or specified by the operator) 


The two-character identifier xx is appended to IEAAPF to identify the IEAAPFxx 
member. If the APF parameter is not specified, only SYS1.LINKLIB and SYS1. ) 
SVCLIB will be authorized (i.e., placed in the APF table). 


Syntax Rules 


The following rules apply to the creation of IEAAPFxx by means of the IEBUPDTE 
utility: 


e@ Place only one library name and corresponding volume serial number on a 
record (card image). 

e Duplicate data set names are valid. 

e On each record, first enter the library name, then one or more blanks, then the 
volume serial number. 

e To continue to another record, place a comma after the volume serial number. 
Omit this comma on the last record. 


Example 
first record: LIBO87 614703, 
second record: LIB122 705650 


IBM-Supplied Default 


If neither IEAAPFxx nor IEAAPFOO exists, SVCLIB and LINKLIB are authorized, 
plus libraries concatenated to LINKLIB via the LNKLSTOO or LNKLSTxx member 
of parmlib. These data sets are always included in the table of authorized program 


libraries. } 


Internal Parameters: Not applicable. 
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Member Name: ITEAAPP00 
Status: New for VS2 Release 2 


Use of the Member 


IEAAPPO0 contains the names of authorized installation-written I/O appendage 
routines. These appendages, when listed, can be used by any unauthorized user 
program. Otherwise, only programs authorized under APF or running under system 
protection key (0--7) may use the EXCP appendages. If your installation does not use ' 
EXCP appendages, you need not create IEAAPPOO. 


IEAAPPO0 can be built during the sysgen process, if the installation specifies any 
of the appendage keywords of the DATASET macro. The possible keywords and the 
associated appendage types are: 


SIOAPP Start |/O appendages 
CHEAPP channel end appendages 
EOEAPP end-of-extent appendages 
PCIAPP PCI appendages 

ABEAPP abnormal end appendages 


NIP accesses SYS1.PARMLIB, reads the list of appendage names in IEAAPPOO, 
builds an appendage name table, and sets a pointer to the table in the CVT. On each 
subsequent OPEN, the appendage name table will be examined, instead of IEAAPPOO. 
If the EXCP caller is not in system protection key or the job step is not authorized, 
Open verifies that the caller’s appendage names are listed. If the names can’t be 
found, Open issues a 913 ABEND. If, however, the caller is authorized, Open loads 
the appendages without inspecting the list. 


IEAPPOO can be created at sysgen, with all appendage names specified, even 
though all appendages have not yet been created. The IEBCOPY step of sysgen will, 
in this case, issue a diagnostic message, but will not fail the step. The installation thus 
has the ability to “prime” IEAAPPOO with appendage names whose modules can be 
created later. To create or alter IEAAPPOO after sysgen, use the IEBUPDTE utility. 
Then re-IPL. 


Rules for Specifying Appendages with the DATASET Macro at Sysgen 


e Use the appendage keywords (e.g., SIOAPP=) for user appendages that are to 
be used by unauthorized problem programs. The full name of an appendage is 
eight characters long. The first six characters must be IGGO19. The last two 
characters, specified as the operands of the appendage keywords, can range 
from WA to Z9. Example: CHEAPP=XZ,ZZ,Z6. 


e@ Specify LPALIB or SVCLIB as the system library parameter. 
e@ Do not use the MEMBERS= keyword (unless the appendages are used 


exclusively by authorized programs). The MEMBERS keyword would prevent 
sysgen from building IEAAPPOO. 
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IEAAPP00 (continued) ) 
e@ Each appendage keyword can list up to 84 appendage-name suffixes(e.g., XZ). 


@ Omit a particular appendage keyword if there are no appendages of that type. 
For example, do not specify EOEAPP if end-of-extent appendages are not 
desired. 


e Omit all appendage keywords, if there are to be no user-written appendages. 
Syntax Example for DATASET Macro: 


The following example shows how the sysgen DATASET macro can be used to 
specify appendage names: 


DATASET  LPALIB 


PDS=MYLIB (user data set from which the appendage modules 
are to be copied to LPALIB) 


MEMBERS=(IGG0O19XX,IGGO19WA) 
SIOAPP=(XY) 
CHEAPP=(XZ,ZZ,ZY) 


In this example six appendages are copied to LPALIB. The two appendages, 

IGG019XX and IGGO19WA, are copied to LPALIB but are not listed in IEAAPPOO. 

These two are to be used only by authorized programs. The other four appendages, | 

a Start I/O and three channel-end appendages, are copied to LPALIB and are listed J 
in IEAAPPOO. 


Syntax Rules 


The following rules apply to the construction of IEAAPPOO by means of the 
IEBUPDTE utility: 


@ IEAAPPOO can contain up to five entries, each entry containing names of a 
particular type of appendage (e.g., abnormal-end or Start I/O). You need not 
necessarily use all five types of entries. 


e Each entry consists of an appendage-type name, followed by a list of suffixes 
of that type, separated by commas. The appendage-type name can start in 
any column. For example: 


SIOAPP WA,W1 
This entry specifies two Start I/O appendages. 


e Indicate continuation, as with most parmlib members, by means of a comma 
followed by at least one blank. The next record can start in any column. 
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TEAAPP00 (continued) 
Syntax Example: 


Here is an example of a complete IEAAPPOO member: 


SIOAPP Y1,Y2, 
EOEAPP X1,W2,X3,X4,X5,X6, 
PCIAPP X3 


Note in this example that there are no channel-end appendages and none for 
abnormal end. Routine IGGO19X3 is used as both end-of extent and PCI appendage. 


IBM-Supplied Default 


If IEAAPPOO doesn’t exist, only IGGO19E4 (channel end/abnormal end appendage 
for Interactive Terminal Facility) is placed in the table of authorized appendage 
routines. 


Internal Parameters: Not applicable. 
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Member Name: IEABLDxx (Resident BLDL List) 


Status 


The purpose of IEABLDO0 is unchanged from MVT, although initial contents from 
sysgen has changed. IEABLDxx, permitting multiple alternate members, was intro- 
duced with VS2 Release 1. 


Use of the Member 


IEABLDxx contains the names of load modules in SYS1.LINKLIB, or any data set 
concatenated to SYS1.LINKLIB, whose data set directory entries NIP will place in 
a pageable or fixed BLDL table. (In MVT, member IEABLDOO contained module 
names for either LINKLIB or SVCLIB. In MVS many SVC modules are included in 
the link pack area.) 


NIP builds a table of data set directory entires for use by LINK, LOAD, ATTACH, 
and XCTL macro instructions. The Program Manager can fetch a requested load 
module from LINKLIB to a paging data set without issuing a BLDL macro to search 
the data set directory, if a resident BLDL entry exists for the module. The fetch in 
this case takes less time than if a BLDL macro had to be issued. 


The created BLDL table will exist in either pageable or fixed storage (but not in 
both) depending on the system parameter specified, BLDL or BLDLF. Altemately, 
you may specify a fixed BLDL table, without naming its contents, by specifying 
the BLDL option of the CTRLPROG macro at sysgen. With either method, you 
create the contents of the table by means of the IEBUPDTE utility. 


There are several ways to reduce fetch time for frequently used modules. One 
way is to select a fixed BLDL table instead of a pageable one. This choice reduces 
the number of page faults, although at a slight cost in real storage (60 bytes per 
directory entry). Additional I/O time can be saved by placing frequently and 
moderately used reentrant and refreshable load modules in the pageable or fixed 
link pack area. Another technique is to add modules to the link pack area extension 
(MLPA) for the life of the current IPL. (For information on creating and extending 
the LPA, refer to the CLPA and the MLPA parameters in the description of member 
IEASYSxx. Additional performance information is provided in the topic “The 
Pageable Link Pack Area: Its Advantages and Use”’ in the System Performance 
Factors chapter.) 


Parameter in IEASYSxx: BLDLF=xx or BLDL=xx 
(or specified by the operator) 


NIP appends the two alphameric characters xx to IEABLD to form the member 
name IEABLDxx. BLDLF specifies that NIP is to create the resident BLDL table 
in fixed (real) storage. BLDL, on the other hand, specifies that NIP is to create the 
resident BLDL table in virtual storage and that the table is to be paged. 
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IEABLDxx (continued) 


The two keywords BLDLF and BLDL are mutually exclusive. If you specify both 
parameters, BLDLF will be accepted and BLDL ignored. In this case, NIP issues an 
informational message. If you specify neither parameter, NIP does not try to find an 
IEABLDxx member. Only IEABLDO0 will be used, and it will be pageable (unless 
the BLDL. parameter of the CTRLPROG macro was specified at sysgen). 


Syntax Rules 


Use the general syntax rules listed in the introduction to this chapter. In addition, 
list the load module names in the same order as they appear in the data set directory, 
that is, in alphameric order, separated by commas. You may include either major or 
alias names. 


IBM-Supplied Default 


The IEABLDOO member is always created at sysgen. The member contains 

either of two versions, depending on whether TSO is requested at sysgen. Both 
versions remain in parmlib, named [EABLDBA (for batch only) and IEABLDTS 
(for mixed TSO and batch). The sysgen-selected version is renamed IEABLDOO and 
is copied into parmlib from APARMLIB. 


Batch Version (IEABLDBA) 


SYS1.LINKLIB HEWL,IEWL,IFOX00,IFOXO1 IFOX02,IFOX03 [FOX04, 
IFOX05 IFOX06,IFOX11,IFOX21 I FOX31,1FOX51, 
IFOX61 [J FOX62,LINKEDIT,LOADER 


TSO/Batch Version (IEABLDTS) 


SYS1.LINKLIB HEWL,IEWL,IFOX00,IFOXO1 .JFOX02 JIFOX03 JFOX04, 
IFOX05, IFOX06,IFOX1 1, TFOX21,1FOX31,IFOXS1, 


IFOX61 I FOX62,LINKEDIT,LOADER, 
ALLOC,ALLOCATE,E,EDIT,LINK, LOGOFF ,LOGON, 
SUBMIT,TEST 


Note 1: HEWL and IEWL are aliases for the Linkage Editor. IFOXxx names the 
Assembler XF. 


Note 2: LNKLSTO0 by default at sysgen time contains SYS1.LINKLIB. The TSO 
modules are in SYS!.CMDLIB which must be concatenated with 
SYS1.LINKLIB via a LNKLST member. 


Internal Parameters: Not applicable. 
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Member Name: IEADMP00 
Status: New for VS2 Release 2 


Use of the Member 


IEADMP00 contains IBM defaults and/or installation parameters for ABDUMP, for 
use when an ABEND dump is written to a SYSUDUMP data set. (For ABDUMP 
parameters associated with a SYSABEND data set, see description of member 
IEAABDOO.) 


ABDUMP parameters fora SYSUDUMP data set may be specified in any of three 
ways: 


e A parameter list pointed to by the DUMPOPT keyword of an ABEND macro 
instruction.* The list can be built by using the list form of the SNAP macro. 
(See ABEND and SNAP macros in OS/VS2 Supervisor Services and Macro 
Instructions for details.) 


e@ Default options contained in IEADMPOO. These options control the content 
of the ABEND dump if the programmer does not include the DUMOPT key- 
word and its associated parameter list with his ABEND, CALLRTM, or 
SETRP macro. If the DUMPOPT keyword is included, the specified options are 
merged with those in IEADMPOO. 


e@ Temporary override options that an operator can specify with a CHNGDUMP 
command. (See warning statement and example of misuse of CHNGDUMP in the 
description of member IEAABDOO. For format and general usage information 
on CHNGDUMP, refer to Operator’s Library: OS/VS2 Reference (JES2).) 


During IPL an information message will notify the operator if IEADMPO0 is 
invalid or can’t be found. No prompting of the operator will occur. If the member 


contains both valid and invalid parameters, an information message will indicate 
the valid options that were accepted before the error occurred. 


Parameter in IEASYSxx: None 
(or specified by the operator) 


Syntax Rules 


Same as for member IEAABDOO. See the description of that member. 


*An ABEND dump can also be invoked by the CALLRTM and SETRP macros. 
(For details, see OS/VS2 System Programming Library: Supervisor. ) 
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IEADMP00 (continued) 


IBM-Supplied Defaults 


The following defaults are automatically placed in IEADMPO0 by sysgen. 


SDATA=(CB,ENQ,TRT),PDATA=(ALLPA,SPLS) 


These options request a dump of the following areas: 


e formatted control blocks for the task 

e formatted enqueue control blocks for the task 

e modules on the link pack area queue and the job pack area queue, and SVC 
modules related to the task 

@ user storage allocated for the task 

@ GIF trace or supervisor incore trace 
(see explanation under TRT parameter) 


Internal Parameters 
Parameter 
SDATA= 


ALLSDATA 


Meaning and Use 


All the following options are automatically specified. 


The following parameters request dump of specific SDATA areas, as indicated: 


NUC 


SQA 


LSQA 


SWA 
CB 


ENQ 


TRT 


Control program nucleus. SQA, LSQA and PSA are 
included. 


The system queue area. 


Local system queue area for the address space, including 
subpools 229 and 230. 


Scheduler work area used for the failing task. 
Control blocks related to the failing task. 


Enqueue control blocks (QCBs and QELs) related to the 
failing task. 


GTF or supervisor trace table depending on whether the 
ABEND occurs after or during IPL, and whether the 
TRACE ON command was issued at IPL. After Master 
Scheduler Initialization, GTF data is displayed if GTF has 
been started. If GTF is not running, and the TRACE ON 
command was issued at IPL, the supervisor trace table is 
displayed. (For the use of the TRACE command, see 
Operator’s Library: OS/VS2 Reference (JES2). 
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IEADMP00 (continued) 
Parameter Meaning and Use 
PDAT A= 
ALLPDATA All the following options are automatically specified. 


The following parameters request dump of specific PDATA areas, as indicated: 


PSW Program status word at entry to ABEND. 

REGS Contents of general registers at entry to ABEND. 

SA or SAH SA requests save area linkage information and a backward trace 
of save areas. This option is automatically selected if 
ALLPDATA is specified. 


SAH requests only save area linkage information. 
JPA Contents of the job pack area that relate to the failing task. 


These include module names and contents. 


LPA Contents of the LPA related to the failing task. These include 
module names and contents. Also includes active SVCs related 
to the failing task. 


ALLPA Contents of both the job pack area and the LPA, as they relate 
to the failing task, plus SVCs related to the failing task. 


SPLS User storage subpools (0Q—127) related to the failing task. 
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Member Name: IEAFIXxx (the “fix” list or fixed LPA list) 
Status: Introduced with VS2 Release 1 


Use of the Member 


IEAFIXxx contains the names of modules from LPALIB, SVCLIB, and LINKLIB 
which will be temporarily fixed in real storage. The duration of this residence is the 
life of the current IPL. The member may be used to temporarily add or replace 
SVC or ERP routines that already exist in the pageable LPA, or which should be 
fixed to improve system performance. Like the temporary modules chosen through 
the MLPA option, fixed LPA modules may not be automatically reactivated by a 
“quick-start” IPL. That is, the fixed LPA can be reestablished only by respecifica- 
tion of the FIX parameter at the quick-start IPL. (A quick-start IPL is one at which 
the CLPA parameter is not specified.) 


Since fixed modules are not paged, I/O time and paging overhead can be saved 
by placing in the fixed LPA moderately used modules from SYS1.LPALIB. When a 
module is requested, the Program Manager searches the list of fixed routines before 
it examines the LPA directory on auxiliary storage. The price for this performance 
improvement is the reduction in real storage available for paging old jobs and starting 
new jobs. Therefore, the fixed LPA should not be made too large, if real storage is 
relatively small (2 megabytes or less). Remember that frequently referenced 
pages will tend to remain in real storage even when they are not fixed. 


You may, however, use the fixed LPA to buy reduced page-fault overhead at the 
expense of some real storage. Such tradeoff would be desirable with a system that 
tends to be CPU bound but which has sufficient real storage. You can implement the 
tradeoff by placing moderate-usage LPALIB modules in the fixed LPA (via parmlib 
member IEAFIXxx), instead of in the pageable LPA. High usage PLPA modules 
probably need not be fixed, since they are referenced frequently enough to remain in 
teal storage anyway. Since now less real storage will be available for pageable pro- 
grams, the System Resource Manager will swap out address spaces that would 
otherwise occupy real core, awaiting CPU availability. 


Modules specified in IEAFIXxx are loaded and fixed in the order in which they 
are named in the member, and are packed without respect to page boundaries. The 
modules’ CDEs are placed on the active LPA queue for easy access by the Program 
Manager. (Note: To keep search time within reasonable limits, do not allow the fixed 
link pack area to become excessively large.) If the first load module of a type 3 or 4 
SVC routine is specified, the SVC table is updated as required. 


Fixed LPA modules may optionally be specified at sysgen by means of the 
RESIDNT keyword of the DATASET macro. Be careful not to specify the same 
module name in both the RESIDNT and the MEMBERS keywords, since the two 
keywords are mutually exclusive, These modules will be listed in member IEAFIX00. 
To specify this list at IPL, the IEASYSxx member or the operator should include 
FIX=00 as a system parameter. 
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TEAFIXxx (continued) ) 


Note: There is a maximum size that the fixed area of real storage can occupy. The 
maximum space taken up by the nucleus, the fixed BLDL table, the fixed LPA, RMS, 
page frame table, etc. cannot exceed half of real storage, up to a maximum of 2 
megabytes. (For information on how to compute the space occupied by fixed areas 
of real storage, refer to the Storage Estimates manual.) 


Parameter in IEASYSxx: FIX= {ca bb. ..) 
(or specified by the operator) bb. .. 


The two alphameric characters aa, bb, etc. are appended to IEAFIX to form the 
name of one or more IEAFIXxx members of SYS1.PARMLIB. NIP defaults to no 
fixed LPA, if you fail to specify the option in one of the following ways: 


e FIX keyword included in the IEASYSxx member. 
e FIX keyword entered by the operator at IPL. 
e RESIDNT keyword of DATASET macro specified at sysgen. 


Syntax Rules 
These rules apply to the creation of IEAFIXxx through the IEBUPDTE utility: 


e The first record should start with the name of the data set from which 
modules will be taken (SYS1. LINKLIB, SYS1.SVCLIB, or SYS1.LPALIB), 
followed by at least one blank. om 

e@ The module names from the specified data set follow the blank(s). Names are 
separated by commas. They need not be in collating sequence. Names may be 
either major or alias names. 

e@ To continue the list, place a comma and at least one blank after the last 
module name on all records except the last. Omit the data set name on 
following record(s) until the data set name changes. 

e@ Place the next data set mame at the start of a new record, followed by at least 
one blank and a new string of module names. 

e Do not place a comma after the last module name of the last data set. 


Syntax Example 

Ist record SYS1.LINKLIB IKJPARS,|IKJPARS2,IKJSCAN, 
IKJEFDOO,IKJDAIR, 

2nd record SYS1.SVCLIB I1GCOOOSC, 

3rd record 1GC09301, |GCO9302, |GC09303 


IBM-Supplied Defaults: None 
Internal Parameters 


This category is not applicable, since module names, not parameters, may appear in 


this member. ) 
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VS2.03.807 


Member Name: IEAIPSxx 
| Status: Introduced with VS2 Release 2 


Use of the Member 


Used by the system resources manager (see chapter entitled ‘““The System Resources 
Manager’’.) 


Parameter in IEASYSxx: IPS=xx 
(or specified by the operator) 


The two-character identifier xx is appended to IEAIPS to specify one of several 
possible parmlib members from which the system resources manager will obtain its 
parameters. (For additional information, see “IPS” in the description of the 
IEASYSxx member, and Part 3: “‘The System Resources Manager.”’) 


Syntax Rules 


| See “Part 3: The System Resources Manager”’. 
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VS2.03.807 


This blank leaf represents pages 64 - 71 which were deleted by Supervisor Performance *2. 
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Member Name: IEALODOO (the “Load List’’) 
Status: Introduced with VS2 Release 1 


Use of the Member 


IEALODOO contains a list of names of the more frequently used modules of the 
pageable LPA. For each name on the list, NIP builds a contents directory entry | 
(CDE) on the active LPA queue in fixed storage. After Initialization, when one of 
the listed modules is requested, the Program Manager searches the active LPA queue, 
finds the module name, and thus avoids a search of the LPA directory in pageable 
storage. Since paging overhead is reduced, performance is improved. Frequently and 
moderately used LPA modules are reasonable candidates for this member. 


Note: Modules in the fixed LPA and modules in the LPA extension (MLPA) also can 
be found without a search of the LPA directory. See the descriptions of the 
IEAFIXxx and IEALPAxx members. For further performance improvements, refer 
to the IEABLDxx and IEAPAKO0 member descriptions, and to the topic “The 
Pageable Link Pack Area: Its Advantages and Uses” in the Performance Factors 
chapter. 


Parameter in IEASYSxx: None 
(or entered by the operator) 


Syntax Rules 


The following rules apply to the creation of IEALODOO by means of the 
IEBUPDTE utility: 


e Separate names of modules with commas. 

e Indicate continuation by a comma after the last module on a record. 

e@ Module names may be either major names or alias names, but they should 
be the same names that appear in SYS1 .LPALIB. 


IBM-Supplied Defaults: None 


Internal Parameters: Not applicable. 
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Member Name: [EALPAxx (Modified LPA List or LPA Extension) 


Status: Introduced in VS2 Release 1 


Use of the Member 


JEALPAxx contains the names of reenterable modules that NIP will load from 
LINKLIB, SVCLIB, and LPALIB as a temporary extension to the existing pageable 
LPA. The extension is.temporary in that the modules will remain in the paging data 
sets and be listed on the active LPA queue only for the life of the current IPL. They 
may not be automatically quick-started, i.e., reinstated without respecification of the 
MLPA parameter. Note that both the LPA extension and the fix list modules 

(those named in IEAFIXxx) avoid a search of the LPA directory by the Program 
Manager when one of the modules is requested. The LPA extension, unlike the fix 
list, however, contains pageable modules which behave in most respects like LPA 
modules. 


You may use IEALPAxx to temporarily add or replace SVC or ERP routines. 
Another possible application would be the testing of replacement LPA modules that 
have been altered by PTFs. 


Modules that have been replaced via IEALPAxx are not physically removed from 
the pageable LPA or from the LPA directory. They are, however, logically replaced 
since when one of them is requested, the Program Manager searches the active LPA 
queue (a chain of CDEs), finds the name of the temporary replacement, and does 
not examine the LPA directory which contains the name of the replaced module. 


If the first load module of a type 3 or 4 SVC routine is added or replaced, the 
SVC table is updated as required. 


aa 
Parameter in IEASYSxx: | MLPA={(aa,bb.. .)} 
(or specified by the operator) 


The two alphameric characters xx are appended to IEALPA to specify the name of 
one or more modified-LPA list members of parmlib. Since the modified LPA is not 
a permanent addition to the LPA, you should probably specify MLPA=xx,etc. in an 
alternate system parameter list (EASYSxx) and not place the parameter in 
IEASYSOO. Alternately, you may have the operator enter the parameter from the 
console. 

The following is an example of the use of an alternate system parameter list to 
specify the MLPA parameter: 


NIP issues the message |EA101A SPECIFY SYSTEM PARAMETERS FOR 
RELEASE 02.00.VS2 
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IEALPAxx (continued) 


The operator responds with SYSP=01 to specify the system parameter list 
IEASYSO1. 


IEASYSO!1 contains: ..,MLPA=00,... 
NIP reads parmlib member IEALPAOO. 


Syntax Rules 


The following rules apply to the creation of IEALPAxx by means of the 
IEBUPDTE utility: 


e Place the data set name (e.g., SYS1.SVCLIB) first on the initial record, 
followed by at least one blank. 


e After the blank, list the modules to be loaded, separated by commas. You 
may use all columns except 72 through 80. 


e Indicate continuation of the list by a comma after the last name on all 
records, except the last. 


e Do not include the data set name on continued records. 
e@ Place a new data set name at the beginning of a record. 
@ You may use either major or alias names, or both. 


e End the last record with one or more blanks. 


Syntax Example 

Ist record SYS1.LINKLIB IKJPARS,IKJPARS2,IKJSCAN, 
IKJEFDOO,IKJDAIR, 

2nd record SYS1.SVCLIB |GCOOOSC, 

3rd record IGCO9301, 1|GCO9302, |GCO09303 


IBM-Supplied Defaults: None 


Internal Parameters: Not applicable. 
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Member Name: [EAOPTxx 
| Status: Introduced with VS2 Release 2 


Use of the Member 


[EAOPTxx contains three parameters that affect swapping decisions by the system 
resources manager (SRM). Two parameters (called resource factor coefficients or 
RFC) are used to weight the recommendations produced by the CPU load balancing 
and I/O load balancing routines. The third parameter (a resource manager constant 
or RMC) is called the Enqueue Residence Value (ERV). It determines the minimum 
period, in terms of CPU execution time, during which the SRM attempts to avoid 
swapping an address space that is enqueued on a system resource for which there is 
contention. For additional information, see “‘Part 3: The System Resources 
Manager’. 


The specification of the entire IEAOPTxx member is optional. Likewise, the 
specification of each category in the member and of each parameter within a 
category is optional. 


Parameter in IEASYSxx: OPT=xx 
(or specified by the operator) 


The two-character identifier xx is appended to IEAOPT to specify one of several 
possible parmlib members that can contain parameters used by the resource 


algorithms of the system resources manager. (For additional information, see 
“OPT” in the description of the IEASYSxx member.) 


Syntax Rules 


| See ‘Part 3: The System Resources Manager’’. 
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This blank leaf represents pages 76 - 77 which were deleted by Supervisor Performance *2. 
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Member Name: IEAPAKOO (LPA pack list) 


Status: Introduced with VS2 Release 1 


Use of the Member 


IEAPAKOO contains the names of groups of modules in SYS1.LPALIB that are 
executed together or in sequence. (As an example, the load modules of a type-4 
SVC routine are called sequentially and executed as a group.) The member is used 
only during a “cold” start (CLPA specified), when the PLPA is loaded from 
LPALIB. 


NIP uses this member to determine the order in which all modules listed in 
JEAPAKOO are to be loaded from SYS1.LPALIB into the pageable LPA. These 
modules are packed together, if possible, on a single page. The purpose is to reduce 
page faults. The LPA can greatly contribute to page faults, since it is highly used. 
The IEAPAKOO list can significantly reduce page faults (and disk arm movement). 


Each group ideally should not exceed 4K bytes in size. If a group exceeds 4K, 
the module in the group that causes 4K to be exceeded, and all later modules in 
the same group, will be loaded at the next page boundary in the LPA. In contrast, 
NIP loads other modules (those not listed in IEAPAKOO) in size order, the largest 
modules first, then the smaller modules. Unused spaces within page boundaries are 
filled, if possible, with modules smaller than 4K. (For information on how the LPA 
is loaded, and LPA performance information, see the topic “The Pageable Link 
Pack Area: Its Advantages and Uses” in the System Performance Factors chapter. 
See module sizes in OS/VS2 System Programming Library: Storage Estimates. ) J 


There are no alternate members for IEAPAKOO. If the member does not exist, 
NIP continues processing without it. 


You should select link pack area programs for inclusion in the system pack list 
to reduce the number of page faults from the pageable link pack area and thereby 
enhance system performance. The affinity of programs for each other and the size 
of the programs determine which should be selected for a pack list entry. Program 
affinity means that one program will usually reference another program when the 
first program is invoked. By putting programs that reference each other into the 
same pack list entry, and thereby on the same page, extra page faults are avoided, 
because the programs are always in real storage together. 


Very large programs which are to be put into the link pack area should be link 
edited so that modules which have affinity* for other modules are placed within 
the same page. The linkedit ORDER statement can be used to group CSECTSs into 
pages. This process will accomplish the same goal as the pack list entries, since page 
faults during execution will be reduced. 





*The modules are either executed at the same time or call each other. J 
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IEAPAKO0 (continued) 


Parameter in IEASYSxx 
(or specified by the operator) 


None, although the member is used only when the CLPA parameter is specified, or 
at the first IPL after sysgen. 


Syntax Rules 


The following rules apply to the creation of IEAPAKOO by means of the IEBUPDTE 
utility: 


e The member consists of “groups” or entries containing load module names. 
Each group is enclosed in parentheses. For example: (IGGO19CM, 
IGGO19CN, IGGO19CO, IGGO19CP, IGG0O19CR). 


@ The modules listed in each group should not exceed 4K bytes in total size. 

e Separate modules within each group by commas. 

e Separate each group from the next by a comma after the closing parenthesis. 
e Do not use alias module names. NIP processes only major names. 


e@ All named modules must be reentrant, since LPA modules must have this 
attribute. 


IBM-Supplied Default 


A minimum LPA pack list is copied at sysgen. The list is supplied as four alternate 
members in the APARMLIB data set: 


JEAPAKTS — _ time sharing and batch system (without VTAM) 
IEAPAKBA — _batch-only systems (without VTAM) 
IEAPAKBV — _batch-only systems with VTAM 

IEAPAKTV — _ time sharing and batch systems with VTAM 


After sysgen, the SYS1.PARMLIB data set contains all four members plus 
IEAPAKOO. IEAPAKO0 is a copy of the member that represents the generated 
system. For example, IEAPAKOO0 is the same as IEAPAKTS if the system is 
generated for TSO without VTAM, or is the same as IEAPAKBA if the system is 
generated for batch only without VTAM, and so forth. The system will use only 
member IEAPAKOO. The other four members are available in SYS1.PARMLIB for 
possible future use by the installation. 


Note: The default pack lists are general purpose lists that may not satisfy all 


installations. Through tracing and other system measurements you may decide on 
changes that best suit your particular needs. 
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IEAPAKO0 (continued) 


Figures 2-6 and 2-7 list the contents of two of the IBM-supplied default pack lists: 
IEAPAKTS and IEAPAKBA. The two lists are identical except for the TSO entries 
at the bottom of Figure 2-6 Figure 2-8 defines the functional module groups that 
comprise the pack list entries in Figures 2-6 and 2-7. Circled numbers cross relate the 
module groups with the related list entries. 


The VTAM IBM-supplied default pack lists, IEAPAKBV and IEAPAKTV, are 
extended versions of IEAPAKBA and IEAPAKTS respectively, with the addition of 
the VTAM modules. IEAPAKBV and IEAPAKTV, along with guidelines for 
repackaging their contents, are described in OS/VS2 System Programming Library: 
VTAM. 





. .NAME=IEAPAKTS,LIST=ALL TSO IEAPAKOO 


(1) (IRBMFTCH,IRBMFEVT,IRBMFEDV,IRBMFECH,IRARMWAR,IRARMSET), 
(A\(1GG019CM,|GG019CN,1GG019CO,IGGO19CP,IGGO19CR), 
(4)(1GG019KU,1GG019L1,1GG019B1,|GG019BM) (6 )11GG0199F,,|GG0199G, IGGo199W, 
IGGO198L), (10) (IGGO19DK,IGGO19BB), @6) (IGC0005B,IGC0205B,1GC0505B), 

7) (1GC0605B,1GC0705B,1GC0805B), (28) (IGCOG05B,1GCOG95B, 1|GC0105B), 

@9) (1GC0J05B,IGCOH05B,IGCOWOSB,1GCOU0SB), BO) (IGCOKO5B,1GCOLOSB,1GCOPO5B), 
G) (1GcososB,1GCOMO5B,|GCOV05B), 62) (IGCONO5B,|GCOROSB,|GCOTOSB), 
(IGCO006C,1GCO106C,1GC0206C, (7) (IGCODOEC,1GCOFO6C,1GCOGOEC), 

(IGCOHO6C, IGCOADEC), (IGCONO6C,1GCOQN6C,1GCOS06C), G9) {IGCO0DEF, 
|GGO860A,1GG0860B,1GG0860C), 40) (1GG0860D,IGGO86AE,1GC0008H), (42) (1GCo008B, 
1GC0108B), 42) (IGCO208B,IGC0308B,1GGO19P7,1GG019P8,1GGO19P9), (43) (IEEVDEV, 
IECVIOPM), 44) (IGCO008A,1GG08101,1GG08102), (45) (1GG08103,IGG08104,1GC0010E), 
(IGCOOOSH ,1GCO109H), 48) (1GC0008C 1 EFU83), 

(1GC0011 ,1GC40110,1GC10110,1GC11110,1GC12110), 
(1GC20110,1GC21110,1GC22110,1GC23110), 62) (IEEVMNT1,IEEPRWI2,IEEPRTN), 
62) (IEFJDSNA,IEFJJTRM,IEFJRASP,IEFJRECM,|EFJSDTN,1EFJSREQ,|EFIRECM), 

63) (EF VGM1,IEFVGM78,1EFVGM2,|EFVGM3,|EFVGM4,|EF VGMS), 64) (IEFVGM6, 
|EFVGM7,|EFVGM70,IEFVGM19,IEFVGM76,lEFVGM8,l|EFVGM17,IEFVGNM9), 

65) (IEFVGM10,IEFVGM11,IEFVGM12,IEFVGM13,|EFVGM14,IEFVGM15,IEFVGM16, 
IEFVGM18), 

G8) (1GG0196S,IGGO19T3 ,1GGO19T4,IGGO19T5,IGG019T6,|GGO19T7,|GGO19T8, TSO 
IGGO19TX,IGGO19TY ,1GGO19TZ) 


Note: The circled numbers are used as references to the functional module groups listed in 
Figure 2-8. These numbers are not contained in the pack list itself. 


Figure 2-6. Default Pack List for Time Sharing and Batch System 
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IEAPAKO0 (continued) 


| NAME=IEAPAKBA,LIST=ALL_ BATCH (NON-TSO) IEAPAKOO 
G) (IRBMFTCH,IRBMFEVT,IRBMFEDV,|RBMFECH,IRARMWAR,|RARMSET), 

(4) (1GG019 CM,1GGO19CN,|GG019CO,1GGO19CP,1GGO19CR), 
(4)(1GG019KU,1GG019L1,1GGO19B1,1GGO19BM), G) (1GG0199F,1GG0199G,1GG0199W, 
IGGO198L), (10) (IGGO19DK,IGG0198B), @6) (IGCO00SB,1GC0205B,1GC0505B), 
(IGCO605B,1GCO705B,IGCO805B), (28) (IGCOG05B,|GCOG95B,|GCOI0SB), 
(1GCOJOSB ,|GCOHOS5B,1GCOW05B, |GCOU0SB), Bd) (1GCOKO5B,1GCOL05B,|GCOPOSB) 
(IGCOSOSB,IGCOMOSB,IGCOVO5B), G2) (IGCONOSB,IGCORO5B,|GCOTOSB), 

G8) (1GC0006C,1GCO106C,1GC0206C), 7 (IGCODOEC,IGCOFOEC,IGCOGOEC), 
(IGCOHO6C,IGCOA0EC), (IGCONOGC,| GCOQN6EC,1GCOSOEC), 9) (IGCOODEF, 
0860A,1GGO860B,1GG0860C), (40) (IGGO860D,1GGO86AE,|GC0008H), 
(1GCO008B,1GCO0108B), @2) (1GCO208B,!GC0308B ,IGGO19P7,1GGO19P8,1GGO19P9), 
(IEEVDEV,IECVIOPM), (44) (1GC0008A,1GG08101,1GG08102), @5) (1GG08103, 
GG08104,1GCO0010E), G6) (IGCOO09H,1GCO109H), @8) (1GCO008C,IEFU83), 
(1GCOO'11 ,1GC40110,1GC10110,1GC11110,1GC12110), 
(1GC20110,1GC21110,1GC22110,1GC23110), G3) (IEEVMNT1,IEEPRWI2,|EEPRTN), 
(IEFJDSNA, IEF JJTRM,|EFJRASP,IEFJRECM,|EFJSDTN IEF JSREQ,|EFIRECM), 
(IEFVGM1 ,|EFVGM78,lEFVGM2,|EFVGM3,IEFVGM4,IEFVGM5), (64) (IEFVGM6, 
|EFVGM7,IEFVGM70,|EFVGM19,|EFVGM76,lEFVGM8,IEFVGM17,|EFVGM9), 

68) (\EFVGM10,IEFVGM11,IEFVGM12,[EFVGM13,IEFVGM14,IEFVGM15,/EFVGM16, 
|EFVGM18) 


QOOOO 


Q) 


G 


@©® 


@OOOO@ 


Note: The circled numbers are used as references to the functional module groups listed in 
Figure 2-8. These numbers are not contained in the pack list itself. 





Figure 2-7. Default Pack List for Batch System 
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Note: Numbers 2, 3, 5, 7-9, 11, 
12-25, 33-35, 47, 56, 57, and 
59-62 have been intentionally 
omitted, since their modules 
are no longer included in the 
PAK list. 
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IEAPAKOO (continued) 


@) Men 


IRBMFTCH 
IRBMFEVT 
IRBMFEDV 
IRBMFECH 


IRARMWAR 


IRARMSET 


(A) Translation Tables 


IGGO19CM TTY,ASCI 
IGGO19CN_ Burroughs, Friden, NCR 


IGGO19CO 
1GGO19CP 
IGGO19CR 


@) BDAM-BSAM 


IGGO19KU 
IGGO19 LI 
IGGO19BI 
1GGO19BM 


(6) SAM-sI 


IGGO199F 
1GG0199G 
IGGO199W 
IGGO198L 


Gd) SAMsI 


IGGO19DK 
IGGO19BB 


BDAM CE Appendage 
BDAM Check 

BSAM Check 

BSAM EOE Appendage 


Checkpoint/Restart 


1GCO005B 
1GCO205B-__—s Restart 
1GCO505B 


Checkpoint/Restart 


1GCO605B 
1GCO705B 
1'GCO805B 


Checkpoint/Restart 


1GCOGO5B 
1GCOG95B 
IGCOI05B 


Checkpoint/Restart 


1GCOJO5B 

IGCOHO5B 
|GCOWO05B 
1GCOU05B 


Checkpoint/Restart 


1GCOKO5B 
|GCOLO5B 
|GCOPO5B 


Checkpoint/Restart 


1GCOSO5B 
|GCOM05B 
|GCOVO5B 


Checkpoint/Restart 


|GCONO5B 
IGCOROSB 
IGCOTO5B 


Figure 2-8. Functional Contents of Default Pack Lists (Page 1 of 3) 





IE APAKO0 (continued) 

Checkpoint Protect, Overlay, Identify 
IGCOO06C IGCOO09H 
IGCO106C IGCO109H Protect 
IGCO206C 

SMF 

G2) Checkpoint 1GCO008C 
IGCODO6C IEFU83 
IGCOFO6C 
IGCOGO6C SVC 110 

Checkpoint, 8A) Checkpoint ae 
IGCOHO6C IGCONO6C 1GC10110 
1GCOAO6C 1GCOQO6C 1GC11110 

IGCOSO6C IGC12110 

ATLAS 60) svc110 
IGCOOO8F 1GC20110 
IGGO860A 1GC21110 
IGGO860B 1GC22110 
IGGO860C 1GC23110 

G0) ATLAS 6) Start/Mount 
IGGO860D IEEVMNT1 
IGGO86AE IEEPRWI2 
IGCO008H IEEPRTN 

IEHDASDR 62) JES2 Initiator 
1GCO008B IEFJDSNA 
IGCO108B lEFJJTRM 

IEFJRASP 

IEHDASDR lIEFJRECM 
pare IEFJSDTN 
eCOa0RE IEFJSREQ 
IGGO19P8 
IGGO19P9 63) Interpreter 

IEFVGM1 

MP Reconfiguration 1EFVGM78 
IEEVDEV _—Device Subroutine Mainline IEF VGM2 
1ECVIOPM _ IOS Operational Path Test IEF VGM3 

IEF VGM4 
@4) SETPRT-3211-IMAGELIBs lEFVGMS5 
IGCOOO8A 
Int 
1GGO8101 2) aerprster 
1GGO8102 IEFVGM6 
IEF VGM7 
G8) SETPRT IEF VGM70 
IEFVGM1 
|IGG08 103 ae 
IGGO8 104 IEEVGMB 
IEF VGM9 





Figure 2-8. Functional Contents of Default Pack Lists (Page 2 of 3) 
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TEAPAKO0 (continued) ) 


65) Interpreter TSO Terminal 1/O Controller (TIOC) 
IEF VGM10 1GGO196S 
IEF VGM11 1GGO19T3 
IEF VGM12 IGGO19T4 
IEF VGM13 IGGO19T5 
IEFVGM14 IGGO19T6 
IEF VGM15 1GGO19T7 
IEF VGM16 1GGO19T8 
IEFVGM18 1IGGO19TX 

IGGO19TY 
IGGO19TZ 


Figure 2-8. Functional Contents of Default Pack Lists (Page 3 of 3) 


Internal Parameters: Not applicable. 
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VS2.03.807 


Member Name: IEASYSxx (System Parameter List) 
Status: Introduced with VS2 Release 1 


Use of the Member 


The system programmer can specify system parameters through a combination of 
three sources: sysgen macros, IEASYSxx members of parmlib, and operator 

| responses to the SPECIFY SYSTEM PARAMETERS message. As many as twelve 
system parameters may be specified through sysgen macros and automatically copied 
to the IEASYSOO member of parmlib. Only one of these parameters, the PAGEDSN 
keyword of the DATASET macro, is mandatory at sysgen. Other parameters, as well 
as these nine, may be placed in the IEASYSOO member or in an alternate system 
parameter list (IEASYSxx), to provide a fast initialization with little or no operator 
intervention. 


Figure 2-9 shows which sysgen parameters are always placed in IEASYSOO, 
which parameters are optionally placed in IEASYSOO, and which NIP parameters 
are equivalent to these sysgen parameters. 








Sysgen Equivalent Related Parmlib 

Macro and Initialization Member 

Parameter Parameter (if applicable) Comments on Sysgen Parameter 
CTRLPROG 

CSA= CSA Parameter is copied to IEASYSOO only if parameter is 
specified at sysgen. 

OPTIONS=BLDL BLDL=00 }EABLDOO BLDL=00 or BLDLF=00 is always copied to IEASYSOO, 

or BLDLF=00 Default contents of IEABLDOO are always copied to 
JEABLDOO from APARMLIB. 

PAGNUM PAGNUM= Parameter is copied to IEASYSOO only if specified at 
SYSGEN. 

REAL= REAL= Parameter is copied to |EASYSOO only if parameter is 
specified at sysgen. 

SQA= SQA= Parameter is copied to IEASYSOO only if parameter is 
specified at sysgen. 

VRREGN= VRREGN= Parameter is copied to IEASYSOO only if parameter is 
specified at sysgen. 

DATASET 

DUPLEXDS,NAME= DUPLEX= Parameter is copied to IEASYSOO only if specified at 
SYSGEN. 

PAGEDSN= PAGE= The specification of at least three DATASET macros with 
PAGEDSN keyword is a required parameter at sysgen, 
without which the sysgen cannot complete. This specification 
causes sysgen to place the PAGE parameter and the specified 
dsnames into IEASYSOO. The dsnames specified with 
PAGEDSN can be changed or added to at IPL. 

RESIDNT= FiX=00 IEAFIXOO FIX=00 is copied to IEASYSOO. The member name specified 
in the RESIDNT keyword is placed in [EAFIXOO. 

SWAPDSN= SWAP= Parameter is copied to IEASYSOO only if specified at 
SYSGEN. 

SCHEDULR 
HARDCOPY= HARDCPY= Default value is SYSLOG, Sysgen places this operand in 


JEASYSOO if HARDCOPY is not specified. 





Figure 2-9. Sysgen Parameters that Are Copied to the IEASYSO0O Member 
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IEASYSxx (continued) 


The installation has the choice of placing all or some system parameters in the J 
IEASYSOO member, and other parameters, or other values of the same parameters, 
in one or more alternate IEASYSxx members. IEASYSOO0 is the likely place to put 
installation defaults or parameters that will not change from IPL to IPL. The system 
programmer can add to or modify sysgen-created parameters in this member by 
means of the IEBUPDTE utility. The alternate IEASYSxx member(s), in contrast, 
should contain parameters that are subject to change, possibly from one work shift 
to another. 


Use of the IEASYSOO member can minimize operator intervention at IPL. Since 
IEASYS00 is read automatically, the operator can respond to SPECIFY SYSTEM 
PARAMETERS by replying END or ENTER or ‘U’, and need not enter 
parameters unless an error occurs and prompting ensues. 


If a parameter list other than IEASYSO0 is desired at a particular IPL, the 
operator must indicate the alternate list by replying SYSP=xx in response to the 
SPECIFY SYSTEM PARAMETERS message. (See the SYSP parameter description 
in this section for additional information.) 


The use of system parameter lists in parmlib thus offers two main advantages: 


» They shorten and simplify the IPL process by allowing the installation to 
preselect system parameters. 
e They provide flexibility in the choice of system parameters. The operator can 
specify SYSP=xx to select one of several alternate lists. - 


The system parameters that sysgen places in IEASYSOO are adequate to 
initialize the system, although additional parameters are desirable. Figure 2-9 lists 
the sysgen parameters that are copied to IEASYSOO. 


Overview of IEASYSxx Parameters 


The following list briefly defines all system parameters that can be placed in an 
IEASYSxx or IEASYSOO member (or specified by the operator).Detailed discussions 
of these parameters are provided in later sections of the IEASYSxx topic. 

Note: PAGE and HARDCPY are the only mandatory parameters that have no 
internal defaults. They must be specified. 
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IEASYSxx (continued) 

Parameter Use of the Parameter 

APF Names the parmlib member (1EAAPFxx) that contains authorized data set 
names. 

APG Specifies the priority value of the automatic priority group for use by the 
System Resource Manager. 

BLDL/BLDLF Names the parmlib member (IEABLDxx) that lists module names that are to 
be placed in a pageable or fixed BLDL table. The choice of BLDL or BLDLF 
determines which table NIP will build. 

CLPA Tells NIP to load the link pack area with the modules contained in 
SYS1.LPALIB. Also purges VIO data sets that were used in the previously 
initialized system. Thus, CLPA implies CVIO. 

CMD Completes the name of the parmlib member (COMMNDxx) that contains 
commands to be issued internally during Master Scheduler Initialization. 
COMMNDxx also controls prompting during TOD clock initialization. 

CSA Specifies the size of the common service area in multiples of 1K bytes. 

CVIO Deletes previously used V1O data sets from the paging space. This parameter 
is automatically included when CLPA is specified. 

DUMP Specifies whether SYS1.DUMP data sets for SVC Dump are to be on direct 
access device(s) or tape, and names the unit address(es) if tape is to be used. 
This parameter can also indicate that no SYS1.DUMP data sets are to be made 
available for SVC dumps. 

DUPLEX Specifies a duplex page data set name or overrides the existing duplex data 
set name. This parameter is ignored on quick starts or warm starts 
(non-CLPA IPLs). 

FIX Completes the name of one or more parmlib members (IEAFIXxx) that 
contain names of modules from SVCLIB, LINKLIB, and LPALIB that are to 
be placed in a fixed LPA that lasts for the life of the IPL. 

HARDCPY Specifies a hard copy log and indicates the types of commands, responses, and 
messages that will appear on the log device. 

IPS Completes the name of the parmlib member (IEAIPSxx) from which the 
system resources manager (SRM) will obtain the installation performance 
specification. 

LNK Completes the name of one or more parmlib members (LNKLST xx) that 
contain names of data sets that are to be concatenated to LINKLIB. 

LOGCLS Specifies the JES output class for the log data sets. 

LOGLMT Specifies the maximum number of WTLs (messages) for a log data set. When 
the limit is reached, the data set is scheduled for sysout processing. 

MAXUSER Indicates the maximum number of address spaces that can be located by 
means of the address space vector table (ASVT). Sets a limit on the number of 
concurrent address spaces. 

MLPA Completes the name of one or more parmlib members (IEALPAxx) that 
name modules to be placed in a temporary LPA extension. 

NUCMAP Specifies that the Dynamic Support System (DSS) resource initialization 
module (RIM) should build a new map of the nucleus in the SYS1.DSSVM 
data set, and overlay the old map, if one exists. 

OPI Indicates whether the operator is to be allowed to override particular 
Parameters, or all parameters, contained in |EASYSxx. 

OPT Completes the name of a parmlib member (IEAOPTxx) that contains 


tuning parameters to be used by the resource algorithms of the System 
Resource Manager. 





Figure 2-10, Overview of IEASYSxx Parameters (Part | of 2) 
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IE ASYSxx (continued ) 

Parameter Use of the Parameter 

PAGE Gives the names of newpage data sets to be used as additions to or replace- 
ments for existing page data sets. The first-named data set is intended for 
exclusive placement of the PLPA. The second-named.-data set is for exclusive 
placement of MLPA and CSA. Replacement is possible only if the parameter 
is placed in |EASYSxx, and the operator selects this member by entering 
SYSP=xx. The PAGE parameter, when specified by the operator, can only 
add temporarily to a parmlib page data set list. 

PAGNUM Specifies the number of page and swap data sets that can be added to the 
system after IPL by the PAGEADD command. 

PURGE Demounts all Mass Storage System volumes. 

REAL Specifies the maximum amount of real storage, in 1K blocks, that can be 
allocated for concurrent ADDRSPC=REAL jobs. 

RSU Specifies the number of storage units that will be available for storage 
reconfiguration in an MP system. 

SMF Specifies a parmlib member (SMFPRMxx) from which SMF will obtain its 
parameters. 

SQA Gives the number of additional 64K segments of the virtual system queue area 
to be created at IPL. 

SWAP Specifies the names of new swap data sets to be used as additions to or 
replacements for existing swap data sets. 

SYSP Specifies one or more alternate system parameter lists (IEASYSxx) that are to 
be read by NIP in addition to IEASYSOO. SYSP may be specified only by the 
operator. 

VAL Names one or more parmlib members (VATLSTxx) that contain ‘‘mount”’ and 
“use” attributes of direct access devices. 

VRREGN Gives the default real-storage region size foran ADDRSPC=REAL job step 
that does not have a REGION parameter in its JCL. 

WTOBFRS Specifies the number of buffers that the Write-to-Operator (WTO) routines 
will use for operator messages. 

WTORPLY Specifies the nurnber of operator reply elements to be used by the Write-to- 


Operator-with-Reply (WTOR) routines. 





Figure 2-10. Overview of IEASYSxx Parameters (Part 2 of 2) 


Changes to Initialization Parameters 


The following lists briefly describe MVT system parameters that are no longer 
supported, and VS2 Release 1 parameters that have changed or that are no longer 


supported. 
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Unsupported MVT System Parameters 


The following MVT system parameters are not supported in MVS, but are provided for by 
comparable MVS functions: 


MIN 


This parameter is not needed in MVS because the Initiator modules are contained 
in the pageable link pack area. 
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IEASYSxx (continued) 


MOD 
The CPU model identification is determined in MVS by the STIDP instruction. 


RAM 
Routines from SYS1.SVCLIB and SYS1.LINKLIB can be added to the MVS link 
pack area by means of the SYS!.LPALIB data set or the MLPA or FIX system 
parameters. 

RERP 
In MVS, error recovery procedure (ERP) routines are always resident in the link 
pack area. 

RSVC 
In MVS, SVC routines are always resident in the link pack area. 

SQS 
This parameter is replaced by the SQA system parameter. 

TMSL 
This parameter is not needed because the System-Resource Manager determines 
the acceptable time slices. 


The following MVT system parameters are not supported in MVS and have no comparable 
MVS functions: 


ALTSYS 
Dynamic device reconfiguration (DDR) for the system residence device is not 
supported. 

HRAM 
MVT hierarchy support is not needed in MVS. 


HSVC 
MVT hierarchy support is not needed in MVS. 


MPS 
It is not necessary to specify the size of the master scheduler region because in 
MVS, the master scheduler task has its own virtual address space. 


QBF 
This parameter is not needed in MVS because the job queue is replaced by the 
sehcduler work area (SWA) and job entry subsystem data sets. 


Changed MVS System Parameters 


APG 
The only value that can be specified for the APG parameter in MVS is the priority 
of the automatic priority group. 

DUMP 
Ten SYS1.DUMPxx data sets can be specified in MVS. 
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PAGE 

Values specified by the PAGE parameter have changed for MVS, because paging 
| | space is made up of preformatted VSAM data sets, at least three of which must 

be defined and formatted either before or during system generation. The first- 
named data set is intended to hold the PLPA. The second-named data set is for 
exclusive placement of common areas excluding PLPA (MLPA and CSA). The 
third and subsequent-named data sets are for non-duplexed areas (that is, private 
address spaces and VIO data sets). The PAGE parameter no longer specifies a 
particular volume or unit to contain the link pack area. 

REAL 
In MVS, the value specified by the REAL parameter represents the total amount 
of ADDRSPC=REAL storage in 1K-byte multiples, as opposed to the number of 
4K-byte blocks added to a 64K-byte minimum value in VS2 Release 1. 


Unsupported VS2 Release 1 System Parameters 


The following VS2 Release 1 system parameters are not supported in MVS, but are provided for 
by comparable MVS functions. 


LSQACEL 
This parameter is not needed in MVS because quickcells for the local system 
queue area are controlled by the Virtual Storage Manager. 
PAL 
The values specified by this parameter are supplied by the address space | 
supervision routines in MVS. ) 
SQACEL 
This parameter is not needed because quickcells for the system queue area are 
controlled by the Virtual Storage Manager. 
TMSL 


This parameter is not needed because the System Resource Manager determines 
the acceptable time slices. 


The following VS2 Release 1 system parameters are not supported in MVS and have no com- 
parable MVS functions. 


AUXLIST 
This parameter is not needed because in MVS each time-sharing user is assigned to 
an individual virtual address space. 

CPQE 
The number of channel programs to be used by the address space supervision 
routines is no longer an installation option. 

MPA 


It is not necessary to specify the size of the master scheduler region because in 
MVS, the master scheduler task has its own independent virtual address space. 
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TRACE 
The system trace option cannot be specified in IEASYSOO or IEASYSxx in MVS. 
It is activated automatically by the system control program during IPL. The 
system trace is continued after IPL if the TRACE ON command is issued at IPL 
before the operator responds to the JES2 SPECIFY OPTIONS message. 


TSOAUX 
It is not necessary to specify auxiliary storage space for time-sharing jobs in MVS 
because each time-sharing user is assigned to an individual virtual address space. 


Parameter Specified by the Operator: SYSP=xx 


The operator specifies this parameter to indicate an alternate system parameter list 
to be used by NIP in addition to IEASYSOO. (See SYSP in “Internal Parameters” 
later in this section.) 


Syntax Rules 


The following rules apply to the creation of IEASYSxx by means of the IEBUPDTE 
utility: 


e@ Use columns | through 71 of each record for parameters. Leading blanks are 
acceptable. 

Do not use columns 72 through 80, since NIP ignores these columns. 
Separate parameters with commas. 

Indicate continuation by a comma, followed by at least one blank. 

Begin subsequent records in any column. 

Enclose multiple subparameters in parentheses. The number of subparameters 
is unlimited. 


Syntax Example: 
.. .DUMP=(TA,282), MLPA=(00,01,02,03,L),BLDLF=02 


IBM-Supplied Defaults 


The default member IEASYSOO, initially created at sysgen, always contains at least 
BLDL=00 or BLDLF=00, HARDCPY, and PAGE. Additionally, particular 
parameters of the CTRLPROG, DATASET, and SCHEDULR sysgen macros are 
copied to IEASYSO0, if the installation specifies them during system generation. 
(See Figure 2-11 for details.) 


Internal Parameters 


The IEASYSxx parameters are listed alphabetically and are individually described. 
These parameters may optionally be issued by the operator, although such manual 
issuance would slow the IPL. 


NOTE: “Value range’’, if applicable, means the syntactically acceptable range of 
values, not necessarily a range of values reasonable for function or performance. 


The “associated parmlib member” refers to the parmlib member that is named by 
the parameter. For example, IEAAPFO!1 is named by the APF=01 parameter in 
IEASYSxx, or entered by the operator. 
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Parameter: APF=xx 


Meaning and Use: The two alphameric characters xx are appended to IEAAPF to 
form the name of parmlib member IEAAPFxx. This member lists the data set names 
and volume serial numbers of authorized data sets. SYS1.LINKLIB and 
SYS1.SVCLIB are automatically included as authorized data sets. SYS1.LPALIB is 
not automatically authorized, since it is used only by NIP. 


The default parmlib member IEAAPFO0 is created at sysgen if the system 
programmer specifies the APFLIB keyword of the CTRLPROG macro. 


Value Range: Not applicable. 
Default Value: SYS1.LINKLIB and SYS1.SVCLIB alone are authorized if APX=xx 
is not specified. In addition, any libraries concatenated to SYS1.LINKLIB are 


also authorized. 


Associated Parmlib Member: ITEAAPFxx 
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IEASYSxx (continued) 
Parameter: APG=nn 


Meaning and Use: The one or two-digit number nn specifies the priority value of the 
automatic priority group (APG). Job steps which do not include the DPRTY key- 
word in their EXEC statements are automatically placed in the APG. DPRTY is 
specified as DPRTY=(value1 ,value2). Job steps for which valuel = APG priority will 
also be in the APG group. Job steps for which valuel is greater than APG will have a 
higher priority than APG-group job steps. Job steps for which value] is less than 
APG will have a lower priority thah APG-group job steps. (Value2 is not used for 
APG. See OS/VS2 JCL for a description of value2.) For further information, 

see ‘Part 3: The System Resources Manager.” 


Value Range: 0—13 
Default Value: 7 


Associated Parmlib Member: None 
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TEASYSxx (continued) ) 
Parameter: BLDLF=xx or BLDL=xx 


Meaning and Use: The two alphameric characters xx are appended to IEABLD to 
form the name of a parmlib member. This member contains a list of module names 
for which NIP builds a list of BLDL entries in the resident BLDL table. 


The installation specifies BLDLF if it wishes the BLDL table to be fixed in real 
storage. Otherwise, it specifies BLDL and the table is pageable. The two keyword 
options are mutually exclusive. If by error, both BLDL and BLDLF are specified, 
NIP rejects BLDL, accepts BLDLF, and issues a warning message. 


Note: At a relatively small expense in real storage, the BLDLF parameter can 
improve performance by reducing the number of page faults. 


Value Range: Not applicable 


Default Value: BLDLF=00 or BLDL=00, since IEASYSOO is always read and 
contains this default. 


Associated Parmlib Member: [EABLDxx (See description of this member.) 
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IEASYSxx (continued) 
Parameter: CLPA (Create Link Pack Area) 


(See also the MLPA parameter for temporary additions to the LPA, and the CVIO 
parameter for the deletion of VIO data sets.) 


Meaning and Use: This parameter causes NIP to load the LPA with all modules 
contained in SYS1.LPALIB. Modules listed in IEAPAKOO are packed together, 
preferably in one-page groups. (See description of IEAPAKOO.) Modules not in the 
pack list (IEAPAKO0) are loaded in size order, large modules first, then smaller 
modules to fill unused space. (For further information, refer to the topic “The 
Pageable Link Pack Area: Its Advantages and Uses” in the System Performance 
Factors chapter.) 


The LPA resides on external page storage. Only one LPA may exist in paging 
space, although the same LPA is duplexed on two separate data sets for error 
| recovery if a duplex data set is specified. Since the LPA is a read-only area, all 
LPALIB modules should be reenterable and refreshable. 


CLPA should be specified after the installation has modified LPALIB and wishes 
to reload the LPA with new or changed modules. 


Note: CLPA also implies CVIO, so that old VIO data sets are automatically purged. 
(See the description of CVIO for further information.) 


The CLPA parameter is not needed at the first IPL. NIP detects the cold start 
condition internally, noting that the LPA has not been loaded and that VIO data 
sets do not exist. 


If CLPA is not specified, NIP tries to find a usable LPA in the existing page data 
sets. If NIP is successful, a Quick Start occurs. In Quick Start, the Auxiliary Storage 
Manager (ASM) obtains the quick start record that describes the existing LPA. It 
then reestablishes the old LPA. The old LPA may be reused for any number of sys- 
tem initializations, as long as CLPA is not specified. However, page data sets that 
contain the last used LPA must be mounted. If they are not, the operator is asked 
to mount them. If he bypasses mounting, ASM Initialization requests a different 
page data set and forces a “cold’’ start. NIP then reestablishes the LPA as it does 
when CLPA is specified. In this cold start, both the previously established LPA 
and existing VIO data sets are logically deleted from paging space. 


The fixed LPA, the LPA extension, and the resident BLDL table, however, are 
not automatically reused in a Quick Start. They must be respecified. Existing VIO 
data sets are also retained, unless the CVIO or CLPA parameter is specified or 
forced. (See description of CVIO parameter.) 


If CLPA is specified and an LPA already exists on a paging data set, NIP frees the 


existing LPA and updates the quick start record to reflect the new LPA. NIP loads 
the LPA from LPALIB, as previously described. 
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Parameter: CLPA (continued) 


After NIP has constructed the LPA, it reads and processes the IEALODOO 
member of parmlib. This member contains the names of LPA modules that the 
installation uses frequently. NIP creates contents directory entries (CDEs) for these 
modules on the active LPA queue. This queue can reduce page faults, because the 
Program Manager can avoid a search of the LPA directory when one of the modules 
on this queue is requested. (See the description of the IEALODO0O member, and the 
topic “The Pageable Link Pack Area: Its Advantages and Uses”’ in the System 
Performance Factors chapter.) 


Note: If you wish to specify a new time interval for the Missing Interrupt Handler 
(MIH), you must ZAP the affected csect and re-IPL, specifying CLPA. The time 
interval is the time between checks by MIH for pending conditions. Possible pending 
conditions include: device ends, channel ends, swaps of Dynamic Device 
Reconfiguration (DDR), and MOUNT commands. 


IBM-supplied csect IGFINTVL provides a time interval of three minutes. To 
change the interval, you should use the AMASPZAP program to modify the csect. 
The JCL and the required control statements are described in OS/VS2 System 
Programming Library: Supervisor. The changed time interval will take effect after 
the next IPL at which the modified csect is loaded. To load the csect, you must 
specify the CLPA parameter at the IPL. (Keep in mind, however, that CLPA J 
implies CVIO, and existing VIO data sets will be deleted. It’s therefore best to do 
the IPL at a power-on, rather than during a work shift.) 


Value Range: Not applicable 


Default Value: Not applicable 


Associated Parmlib Member: None 
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° = — 
Parameter: CMD ae , 


Meaning and Use: The two alphameric characters (e.g., 01, OB) specify one or more 
COMMNDxx members of parmlib. The installation can specify multiple members. 
Each member can contain automatic operator commands that the installation wants 
executed during Master Scheduler Initialization. Examples of such commands are 
those that start GTF and TCAM. JES2 commands are not accepted, since automatic 
commands are processed before JES2 is started. 


If the CMD parameter is not specified, the COMMNDOO member is used if it 
exists. If COMMNDOO does not exist or cannot be read, Initialization continues 
without any internally issued commands, and without prompting for TOD clock 
initialization. 

Value Range: Not applicable 
Default Value: CMD=00 


Associated Parmlib Member: COMMNDxx (See description of this member.) 
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IEASYSxx (continued) 
Parameter: CSA=nnnn 


Meaning and Use: This parameter specifies the maximum size of the virtual 
common service area (CSA) in multiples of 1K (1024 bytes), rounded to the next 
segment (64K) boundary. 


Example: CSA=200 could provide a CSA of 256K bytes (200 + 64 = 3 segments 
+ 8K) so that the boundary between the CSA and the user area would be on a 
segment boundary. 


The CSA is an address range in each address space that is used for common 
system functions (i.e., functions not related to a particular address space). For 
example, the system allocates buffers for LOG and SMF, as well as work queue 
elements and reply buffers, from the CSA. The CSA is duplexed for recoverability, 
as are the other common areas, PLPA and MLPA, when a duplex page data set is 
being used. 


In selecting a value for the CSA parameter, choose a value somewhat larger than 
you think you need. There are two reasons: 


e If the Virtual Storage Manager runs out of SQA, it will try to obtain space 
from the CSA. If it cannot do so, it will place the system in a disabled wait 
state. 


e A large CSA size will reserve space for future LPA growth. Such growth 
would be hampered if users were allowed to obtain very large private areas. 
A large CSA specification effectively limits the maximum private area that 
a user job can acquire. 


Notes: 

1. You can also specify the CSA parameter by means of the CSA keyword of 
the CTRLPROG macro at sysgen. In this case, the specified CSA value is 
automatically placed in member IEASYSOO. 

2. For storage overviews and for a method of calculating CSA, refer to 
OS/VS2 System Programing Library: Storage Estimates. 


Value Range: 0—9999 


Default Range: 100 (This means 128K, since the value is rounded up to the next 
segment boundary.) 


Associated Parmlib Member: Not applicable 
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Parameter: CVIO (Clear VIO) 


Meaning and Use: This parameter specifies that all VIO data sets are to be deleted 
from page space. A typical application would be the purging of VIO data sets when 
the system is re-IPLed after a previous end-of-day (EOD). 


Note: If you wish the Auxiliary Manager to purge and reinitialize both VIO data 
sets and the LPA, specify CLPA. CLPA always implies CVIO. 


If neither CVIO nor CLPA is specified, VIO data sets will be retained for restart 
processing. Such restart would be possible for some data sets after a temporary 
system failure. Reuse of VIO data sets occurs independently of a warm start of the 
job entry subsystem. That is, if neither CLPA nor CVIO is specified, the Auxiliary 
Storage Manager reestablishes the VIO data sets that were checkpointed before the 
system failure. This action, of course, does not ensure that the job entry subsystem 
will reuse these data sets. 


When neither CVIO nor CLPA is specified, one or more volumes that contain 
VIO pages may possibly not be mounted. The Auxiliary Storage Manager (ASM) 
requests the operator to mount the missing volume(s). If the operator doesn’t 
mount all the requested volumes, ASM deletes all VIO data sets, just as if CVIO 


or CLPA had been specified. The operator receives a message that indicates that 
CVIO has been forced. 


Value Range: Not applicable 
Default Value: None 


Associated Parmlib Member: None 


Part 2: System Initialization -PARMLIB Members 99 


IEASYSxx (continued) 


NO 

DASD 

L 

(TA,unitaddr1 ,unitaddr2. . .) 


Parameter: DUMP = 


Meaning and Use: This parameter specifies whether SYS1.DUMP data sets for SVC 
Dump are to be on direct access device(s) or tape, and names the unit address(es) if 
tape is to be used. Optionally, the parameter can specify (via NO) that no SVC dump 
data sets are to be made available. (All three options — DASD, L, and TA — may be 
specified with a single DUMP parameter, if so desired.) SVC Dump options are not 
included in parmlib. However, the installation can specify the options, if it so 
desires, by means of the CHNGDUMP operator command. 


Operand Descriptions: 


NO 
specifies that no dump data sets will be available for SVC Dump. 


DASD 
specifies that the currently cataloged SYS1. DUMPnn data sets (if any) on 
permanently resident direct access volumes, are to be used. This operand is the 
default if the DUMP parameter is omitted. 


is used with DASD to specify that cataloged SYS1.DUMPnn data sets are to be 
listed on the operator’s console, with the status of empty or full. Empty means 
the data set is unused or is reusable; full means the data set is used and is ready 
to be printed. A message prompts the operator for the namesof full data sets 
that he doesn’t want to print. SVC Dump will reuse these data sets. The operator 
can also specify in his reply the unit addresses of additional tape units on which 
dump data can be written. 


(TA,unitaddrl ,unitaddr?2. . .) 
specifies that the tape unit at unitaddr is to be used as an SVC Dump data set. If 
both this operand and the DASD operand are specified, the tape unit(s) are added 
to the available direct access dump data sets. If DASD is not specified, only the 
named tape units are made available. 


Examples of Valid DUMP Statements: 


DUMP=NO 
DUMP=DASD 
DUMP=(DASD,L) 
DUMP=(DASD,L,(TA,282,283)) 
DUMP=(TA, 282) 
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JIEASYSxx (continued) 
Parameter: DUMP (continued) 


How Dump Data Sets Are Used: Dump data sets may be all on tape, all on direct 
access devices, or on a combination of devices. Direct access data sets must be 
preallocated and cataloged. Eligible device types consist of unlabeled 2400-series 
tape, 9-track (or tape compatible with 2400-series), and any of the following direct 
access devices: 


2314 

2319 

3330 
3330-1 
2305-1 
2305-2 
3340/3344 
3350 


As many as ten dump data sets may be allocated. Direct access data set names 
must be in the form SYS1.DUMPnn, in which nn may be digits 00 to 09. Since each 
direct access data set will contain only one dump, the installation should allocate it 
with sufficient space for the maximum size SVC dump it expects. The dump size 
depends on the SDATA options that are specified in the console DUMP command, 
or on the overriding options that are specified in the CHNGDUMP command. (For 
information on these commands, refer to Operator’s Library: OS/VS2 Reference 
(JES2).) 


Requirements for Dump Data Sets: Dump data sets must meet the following 
requirements: 


e A data set can reside on only one volume; that is, a data set can’t span across 
two or more volumes. 

e Each direct access data set can contain only one dump. 

e Direct access data sets must be on permanently resident volumes and be 
allocated, and cataloged. (For further information on the permanently resident 
attribute, see the description of the VATLSTxx member of parmlib.) 

e DD statements for direct access data sets must not specify a secondary 
quantity in the SPACE parameter. 


Processing of Dump Data Sets: The status and type of each dump data set is 
maintained in an internal table by SVC Dump. The data sets are processed in the 
order in which they are specified as operands of the DUMP parameter. If, for 
example, the parameter statement specifies DUMP=(TA,283),DASD,(TA,285), the 
first table entry would be for (TA,283). This would be followed by entries for 
cataloged DASD data sets on permanently resident volumes, in the order 
SYS1.DUMPO00 to SYS1.DUMPO9. Only ten data sets are processed. The last table 
entry is for (TA,285), unless the limit of ten data sets has already been reached. 
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IEASYSxx (continued) 
Parameter: Dump (continued) 


Each table entry reflects the data set status, empty or full. An empty data set is 
available for use by SVC Dump. A full data set can either be printed via 
AMDPRDMP, or optionally reused for a new dump. The data set is reused if the 
operator replies to message IEA877A by entering the data set name or tape unit 
address. For example, the operator replies to message IEA877A: R00, 

*‘DA=(xx, yy),(TA,tt,uuu)’. The characters xx,yy are the last two digits of two 
direct access data sets, named SYS1.DUMPxx and SYS1.DUMPyy. They are 
currently full but are to be reused. The characters tt,uuu are the unit addresses 
of two additional tape drives that are to be used for dump data sets. 


The criteria that determines whether a dump data set is empty or full depends on 
the device type, DASD or tape. A tape is always considered empty. A DASD data 
set is empty only if the first record is “end of data”. Otherwise, the data set is 
considered full. 


SVC Dump examines the data sets, as listed in the table, in sequence. If a data 
set is empty, SVC Dump uses it and marks the table entry accordingly. If a data set 
appears full, it is marked as being used and is skipped. When all data sets have been 
marked in use, SVC Dump reads the first record of each DASD data set to see if it 
has been emptied (printed) by AMDPRDMP. If so, the first record is “end of data”. 
SVC Dump updates the table to reflect the current status, then reexamines the data 
sets, starting at the beginning of the table. 


Value Range: Not applicable 
Default Value: DASD 


Associated Parmlib Member: None 
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Parameter: DUPLEX=dsname 


Meaning and Use: The DUPLEX parameter allows the user to specify a paging data 
set to be used to hold a secondary copy of all common area system pages (all pages 
written to the PLPA or common page data sets). Only one duplex data set may be 
specified. The duplex parameter is valid only on a cold IPL(CLPA). On either 
quick or warm IPLs, ASM ignores the DUPLEX parameter and attempts to use the 
same duplex page data set specified on the cold IPL. If no duplex page data set 
was then specified, or if it is otherwise unavailable, duplexing is suspended. This 
parameter follows all of the normal override rules for system parameters. 


How the Duplex Page Data Set Is Specified: On a CLPA IPL, the duplex page data 
set is specified from one of two sources: 1) IEASYSOO or IEASYSxx, or 

2) the operator-specified DUPLEX parameter. On a non-CLPA IPL, the duplex 
page data set is specified from only a single source: the temporary page activity 
reference table (TPARTBLE). An outline of these specifications is as follows: 


e CLPA IPLs — 


— The DUPLEX parameter in IEASYSO0: This data set name is specified 
along with the DUPLEXDS! keyword of the DATASET macro during 
system generation. 


— The DUPLEX parameter in IEAS YSxx, an alternate system parameter 
list: If the operator selects this list (by using the SYSP parameter), the 
DUPLEX parameter in IEASYSxx overrides the DUPLEX parameter in 
IEASYSO0. 


— The DUPLEX parameter specified by the operator in the current IPL: 
This DUPLEX parameter specification is not merged with that specified 
by IEASYSxx, as is the case with the PAGE parameter specification, but 
overrides those specifications. The operator specification lasts until the 
next cold IPL. 


e Non-CLPA IPLs — 
— TPARTBLE: The temporary page activity reference table occupies the 
first 8K of the PLPA page data set. It contains previously specified page 


data sets — including the previous duplex page data set — which will be 
used for the current IPL. 


'The DUPLEXDS keyword causes the DUPLEX parameter to be placed in 
IEASYSOO. 
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IEASYSxx (continued) ) 


Before an IPL, the page data set specified through the DUPLEX parameter, or 
through the sysgen DATASET! macro, must have been allocated, cataloged in the 
system master catalog, and preformatted in VSAM format with track overflow. 
This data set is a normal page data set used for duplexing. The data set can be 
formatted by using the DEFINE PAGESPACE processor of access method services 
as described in OS/VS2 Access Method Services. 


Syntax Example for the DUPLEX Parameter: 
Example 1: DUPLEX=dsname 


When specified on a cold IPL, this statement causes ASM to use the specified 
data set for duplexing the common area pages. 


Note that neither UNIT nor VOLSER is specified. Because all data sets used as 
paging data sets must be cataloged, ASM initialization does not need externally 


specified volume serial numbers. The operator may either premount the necessary 
volumes or await a mount message. 


When the duplex data set gets full, ASM issues a message stating that duplexing 
has been suspended. Once suspended, duplexing can only recommence after a 
subsequent IPL. (See “Part 2.1: Auxiliary Storage Management Initialization” 
space requirement guidelines for duplex data sets.) 

Value Range: Not applicable. 
Default Value: None. 


Associated Parmlib Member: None. 


‘For information about creating page data sets with the sysgen DATASET macro, J 
refer to OS/VS2 System Programming Library: System Generation Reference. 


102.2 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2.03.807) 


IEASYSxx (continued) 


; _Jj aa 
Parameter: FIX a 


Meaning and Use: This parameter specifies one or more IEAFIXxx members of 
parmlib. The two alphameric characters are appended to IEAFIX to name the 
member(s). The member(s) contain names of modules from SVCLIB, LINKLIB, and 
LPALIB that are to be fixed in real storage as a temporary fixed LPA. The fixed 
LPA modules are active only for the life of the current IPL and may not be auto- 
matically reinstated by a Quick Start. You must respecify the FIX parameter in 
subsequent IPLs if you want to reinstate the fixed LPA. 


Note: The FIX parameter may also be specified by using the RESIDNT keyword 
of the DATASET macro at sysgen. In this case, FIX=00 is automatically placed in 
member IEASYSO0O, and the library specified by the RESIDENT keyword is listed 
in parmlib member IEAFIXO0O. (For additional information on the FIX option, 
refer to the description of the IEAFIXxx member. For information on the other 
temporary LPA option, see the descriptions of the MLPA parameter and the 
IEALPAxx member.) 


Value Range: Not applicable 


Default Value: FIX=00, if the installation specified the RESIDNT keyword of the 
DATASET macro at sysgen. 


Associated Parmlib Member: [EAFIXxx 
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IEASYSxx (continued) 
Parameter: 
CMDS 
ener ee | ae | | a seein a eros 
NOCMDS 


Meaning and Use: This parameter specifies a hardcopy log, which may record 
messages, operator commands, and system commands and responses. The parameter 
is new to IEASYSxx. It was formerly only a parameter of the SCHEDULR sysgen 
macro. Now it may be specified at either or both sysgen and Initialization. 


A hardcopy log is required in either of two cases: 


e The system has more than one active console, 
or 
e The system has an active graphic console. 


Note: In either of these two cases, routing codes 1 through 4, and 7, 8, and 10 need 
not be specified, since the system will automatically assign them. 


Operand Descriptions: 


SYSLOG 
specifies the system log as the hardcopy log. 


Note: If the SYSLOG specification is in effect and the subsystem reaches the WTO 
buffer limit before completing its processing, a WAIT condition in which hardcopy 
messages cannot appear on SYSLOG can occur because the subsystem is waiting for 
message buffers. If this condition does occur, the operator should issue a VARY 
command to direct hardcopy to another device. 


address 
is the unit address of a hardcopy console that has at least output capability. 


Note: One of these operands must be specified. If SYSLOG was specified at sysgen 
in the HARDCOPY parameter of the SCHEDULR macro, the unit acc must be 
specified at Initialization. 25 


The following device types are eligible for the unit address operand: 


1052-7 3286-1, 2 
1443-N1 1403 
3210 2740-1 
3215 3211 
3213 3284-1, 2 


ALL 
specifies that all WTO and WIOR messages issued with routing codes will be 
displayed on the hardcopy log. 
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Parameter: HARDCPY (continued) 


(routecode1 ,routecode?. . .) 
is a list of numbers ranging from 1 to 15 that designate the routine codes of 
messages that the hardcopy log is authorized to receive. The list must be 
separated by commas and enclosed in parentheses. If a hardcopy log is required, 
any of the following routing codes are automatically assigned and therefore need 
not be specified: 1—4, 7, 8, 10. (See the previous description of conditions under 
which a hardcopy log is required.) 


CMDS 
specifies that operator commands, and system commands and responses, will be 
displayed. This operand is the default for the various command operands. It is 
automatically assigned by the system, if there is an active graphics console or 
there is more than one active console. In either case, a commands operand other 
than CMDS is ignored. 


INCMDS 
specifies that operator commands, system commands, and in-line responses will 
be displayed. 


STCMDS 
specifies that operator commands, system commands, in-line responses, and 
static status displays will be written out. 


NOCMDS 
specifies that no commands or responses are to be displayed. 


Value Range: Not applicable 

Default Value: The full set of HARDCPY operands can be in IEASYSO0 if the 
HARDCOPY keyword of the SCHEDULR macro was specified at sysgen. If 
HARDCOPY was omitted at sysgen, the default in IEASYSOO is only SYSLOG. In 
this case, you must specify a unit address in the HARDCPY parameter at IPL. 


Associated Parmlib Member: None 
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Parameter: IPS=xx 


Meaning and Use: This parameter specifies the particular installation performance 
specification (IPS) that will be used by the system resources manager. 


The two alphameric characters, represented by xx, are appended to IEAIPS to 
form the name of an IEAIPSxx member of parmlib. 


If the member can’t be found or contains invalid specifications, the initialization 
| routine of the system resources manager prompts the operator to specify an 

alternate member, i.e., respecify IPS=xx. If the operator chooses to reply END or 
ENTER, the System Resource Manager tries to use the default member IEAIPSOO. 
If IEAIPSOO is invalid or unavailable, the System Resource Manager uses an internal 
set of IPS values, called the ‘‘skeleton IPS’’. The skeleton IPS avoids service rate 
distinctions among any jobs. It is merely a stopgap IPS intended to permit the 
completion of IPL. 


The operator can select a new IPS (i.e., indicate that the system is to run under 
the control of an alternate IEAIPSxx member) between IPLs by issuing the SET IPS 
command. When the SET IPS command is processed, any ongoing transactions 
that are associated with performance groups whose definitions have changed in the 
new IPS, will be associated with the first performance group period of the new 
performance group (that is, the previous transaction is ended, and a new transaction 
is started, before processing continues). If the performance group with which 
ongoing transactions were previously associated is not defined in the new IPS, they 
will be associated with the appropriate default performance group (1 for batch 
users, 2 for TSO users). The operator can also change the PERFORM parameter 
(thus the performance group) of an ongoing job or TSO session by issuing the 
RESET job name, PERFORM=nnn command. (Refer to Operator’s Library: OS/VS2 
Reference (JES2} for detailed syntax information on these commands. 


Value Range: Any two-character alphameric combination. 
Default Value: IPS=00. The IEAIPSOO default member, supplied by IBM, can be 
modified by the installation. The use and contents of this default member are 


described under “Default IPS” in “Part 3: The System Resources Manager”. 


Associated Parmlib Member: IEAIPSxx 
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: = aa 
Parameter: LNK | (aa,bb. . 43 


Meaning and Use: This parameter specifies particular LNKLSTxx member(s) of 
parmlib. The two alphameric characters, represented by xx, are appended to 
LNKLST to form the name of the LNKLSTxx member(s). 

The LNKLSTxx member(s) list data sets that are to be concatenated to 
SYS1.LINKLIB. (For information on the use, contents, and syntax of this member, 
see the description of member LNKLSTxx.) 

Value Range: Any two alphameric characters. 
Default Value: LNK=00, causing selection of LNKLSTOO. 


Associated Parmlib Member: LNKLSTxx 


Part 2: System Initialization -PARMLIB Members 107 


IEASYSxx (continued) 


Parameter: LOGCLS=x 

Meaning and Use: This parameter specifies the JES output class for the log data 
sets. A log data set is queued to this class when its WTL limit has been reached. (The 
limit is specified by the LOGLMT initialization parameter.) 

Example: LOGCLS=L 


In this example, the current log data set is queued to output class L when the limit 
on the number of WTLs has been reached. 


If the specified LOGCLS value is invalid, or an I/O error occurs while the 
IEASYSxx member is being read, Master Scheduler Initialization prompts the 
operator for a replacement LOGCLS value. If prompting is forbidden (i.e., the OPI 
operand was specified), the default value A is assigned. 

(For the other log parameter, see LOGLMT.) 

Value Range: A single alphabetic or numeric character: A—Z or 0—9. 


Default Value: A, which represents output class A. 


Associated Parmlib Member: None 
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Parameter: LOGLMT=nnnnnn 


Meaning and Use: This parameter specifies the maximum number of WTLs (i-e., 
messages) allowed for each log data set. The value is used by Log processing to 
determine when a log data set should be scheduled for sysout processing by JES. 
When the value is reached, Log processing issues a simulated WRITELOG command 
to allocate and open a new log data set, and to close and free the current log data 
set. 


Example: LOGLMT=004852 

In this example, when 4,852 WTLs have been issued to a log data set, the data set 
is scheduled for sysout processing on the output class specified by the LOGCLS 
parameter. Log processing then switches log data sets. 

If the specified valie is invalid or an I/O error occurs while the IEASYSxx 
member is being read, Master Scheduler Initialization prompts the operator for a 
replacement LOGLMT value. If prompting is forbidden (i.e., the OPI operand was 
specified), the default value of 500 is assigned. 

(For the other log parameter, see LOGCLS.) 

Value Range: 000000—999999 
Default Value: 500 


Associated Parmlib Member: None 
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IEASYSxx (continued) 
Parameter: MAXUSER=nnnn 


Meaning and Use: This parameter specifies the maximum number of concurrent 
jobs and started tasks that the installation wishes to allow. The number includes 

| time sharing jobs, batch jobs, started system tasks, the Master Scheduler, and JES2. 
The number determines the maximum number of entries in the address space vector 
table. (The address space vector table is used to locate the various address space 
control blocks.) 


| The MAXUSER value sets the limit on the number of concurrent jobs, by 
limiting the number of concurrent address space control blocks. 


MAXUSER must be at least one more than the sum of: the number of JES2 
batch initiators; the number of subsystems; the maximum number of logons; the 
maximum number of started tasks, excluding initiators. In general, the installation 
should set the MAXUSER value as high as the largest expected number of con- 

| current jobs. 


Value Range: 0—9999. The MAXUSER value determines the extent of the search 
of the address space vector table during job step timing. An installation could 
reduce this search time by reducing its MAXUSER value, if possible. 

Default Value: 256 


Associated Parmlib Member: None 


110 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2.03.807) 


JEASYSxx (continued) 


: aa 
Parameter: MLPA | (aa,bb. . .) 


Meaning and Use: This parameter specifies one or more IEALPAxx parmlib 
members, which list modules to be added to the pageable LPA, as a temporary LPA 
extension. Each member lists the names of modules to be loaded from LINKLIB, 
SVCLIB, and LPALIB. 


The installation can use this parameter to temporarily update an existing LPA at 
a Quick Start (i.e., without creating a new LPA through the CLPA parameter). The 
added modules are temporary in that they remain as an LPA extension only for the 
life of the current IPL. The temporary modules may not be automatically reinstated 
by a Quick Start. That is, the MLPA parameter must be specified again in the next 
IPL to reinstate the LPA extension. 


If the installation wants to retain the temporary modules as a permanent part of 
the LPA, it should use the IEBCOPY utility or the Linkage Editor to place the 
modules on SYS1.LPALIB, and specify the CLPA parameter at a future IPL to load 
LPALIB into the LPA. 

(For additional information on the MLPA option, see IEALPAxx. For 
information on the other temporary LPA option, see the FIX parameter and the 
IEAFIXxx member.) 

Value Range: Any two alphameric characters, repeated if desired. 
Default Value: None. If MLPA is not specified, no LPA extension is created. 


Associated Parmlib Member: [EALPAxx 
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IEASYSxx (continued) 
Parameter: NUCMAP 


Meaning and Use: This parameter specifies that NIP’s DSS* resource initialization 
module (RIM) sould create a new map of the nucleus in the SYS1.DSSVM data set, 
and overlay the old nucleus map, if one exists. 


The SYS1.DSSVM data must exist. NIP’s DSS RIM issues a LOCATE, MOUNT, 
and OPEN for the data set. If the data set can’t be found, NIP goes into a wait state. 


NUCMAP must be specified if a// the following conditions exist: 

e@ The nucleus has been modified, perhaps by a PTF, and 

e A nucleus map already exists from a previous IPL, and 

e The nucleus load module name has not changed. 

The parameter need not be specified again at a future IPL, unless the nucleus is 
again modified without a change in load module name. NIP’s DSS RIM automatically 
creates a new nucleus map (i.e., NUCMAP need not be specified) if: 

e@ The name of the nucleus load module changes between IPLs, 


or 
e No nucleus map exists because this is the first IPL after sysgen. 


Value Range: Not applicable. 
Default Value: None 


Associated Parmlib Member: None 





*Dynamic Support System, an FE debugging tool. 
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YES 
NO 


Parameter: OPI= 


Meaning and Use: This parameter specifies whether the operator is to be allowed to 
override system parameters contained in IEASYSxx members of parmlib. The YES 
operand allows operator overrides. The NO operand causes overrides to be ignored. 
If, however, NIP detects an invalid parameter in an IEASYSxx member in which 
OPI=NO applies, NIP ignores the OPI specification and prompts the operator. 


OPI may be specified only in an IEASYSxx member; it may not be specified by 
the operator. 


OPI may be specified either for individual system parameters or for the entire set 
of parameters. 


Examples: 
IEASYSAA: MLPA=(00,01), SQA=(10,OPI=NO) 
IEASYSBB: MLPA=(00,01),SQA=10,OPI=NO 


For IEASYSAA, the operator can override MLPA values but not the SQA value. 
For IEASYSBB, however, the operator can override neither MLPA-nor SQA values. 


Value Range: Not applicable 
Default Value: YES 


Associated Parmlib Member: Not applicable 
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Parameter: OPT=xx 


Meaning and Use: This parameter specifies a parmlib member that contains tuning 
parameters used by the resource algorithms of the System Resources Manager (SRM). 
The two alphameric characters, represented by xx, are appended to IEAOPT to form 
the name of the IEAOPTxx member. 


If the parameter is not specified, internal default values are used but no message 
is issued. If an invalid parameter is detected in IEAOPTxx, a message is issued to the 
operator*, and the SRM uses internal defaults for the parameters normally furnished 
in IEAOPTxx. (See description of member IEAOPTxx in “Part 3: The System 
Resources Manager’ for the default values.) The operator can either accept use of 
the defaults, or re-IPL to specify a replacement OPT value. 


If the SRM can’t find the specified member, it prompts the operator to supply a 
new value for OPT. 


Value Range: Any two alphameric characters. 


Default Value: None. If OPT is not specified, the SRM uses internal defaults. (See 
JEAOPTxx for the internal default values.) 


Associated Parmlib Member: IEAOPTxx 





*Message IEA874I is issued. 
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dsname 

Parameter: PAGE= { (dsnamel ,dsname2, .. .[ ,L]) 
(,L) 


Meaning and Use: This parameter allows the installation to name page data sets as 
additions to or replacements for existing page data sets. The maximum number of 
page data sets is 64, which includes the page data set specified by the DUPLEX 
parameter. To replace page data sets, the parameter must be in IEASYSxx, and 
the operator must select this member by entering SYSP=xx. To add a parmlib 
data set list, it is necessary only that the operator specify the PAGE parameter at 
the console. 


If the ““L” keyword is specified — either in parmlib or from the operator’s 
console — ASM generates a list of all the page data sets that the initialization 
routines have opened. This list is then printed at the operator’s console. 


ASM interprets the sequence of data set names specified as follows: 


e The first named data set on the list is used as the PLPA page data set. This 
data set contains all of the link pack area pages. 


@ The second named data set in the list is used as the common page data set. 
This data set contains all of the common area pages that are not LPA pages. 


e@ The third and all subsequently named data sets are used as local page data 
sets. These data sets contain all the system pages (including VIO pages) that 
are considered neither PLPA nor common data set pages. 


When defining page data sets, you must ensure that the desired PLPA page data set 
is the first entry in the data set list, in both IEASYSOO and IEASYSxx. For 
IEASYSO0, this means that the desired data set name must be in the first sysgen 
DATASET macro containing the PAGEDSN keyword. 


During ASM initialization, there are no checks on the sizes of user-supplied data 
sets. For this reason, the user must define data set sizes prudently. Also, there 
must be at least three page data sets available for IPL: the PLPA page data set, the 
common page data set, and at least one local page data set. 


The data set intended for PLPA should contain enough space for the entire 
PLPA. If the entire PLPA cannot fit on this data set, ASM puts the excess on the 
common page data set. Likewise, if the common page data set gets full, its excess 
goes to the PLPA page data set. In the interest of good performance, however, 
you should make the common page data set big enough to prevent its “spilling 
over” to the PLPA page data set (except in cases forced by error situations). For 
specific data set size and placement recommendations, see “Part 2.1: Auxiliary 
Storage Management Initialization’. 
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How Page Data Sets Are Specified: Page data sets are specified by a merging of 
information from three sources: 1) IEASYSOO or IEASYSxx; 2) operator-issued 
PAGE parameter; and 3) the temporary page activity reference table 
(TPARTBLE). The system merges this information as follows: 


e From the PAGE parameter inIEASYSO0: These data set names were 
specified in the PAGEDSN keyword of the DATASET macro during system 
generation. 


e From the page parameters in IEAS YSxx (an alternate system list): If the 
operator selects this list by using the SYSP parameter, the PAGE parameter 
in IEASYSxx overrides the PAGE parameter in IEASYSOO. The overriding 
parameter can either increase or decrease the number of data sets defined 
during system generation. 


e From the PAGE parameter specified by the operator in the current IPL: The 
system merges this page specification with that in either IEASYSO0 or 
IEASYSxx, but not both. The operator specification of page data sets lasts 
only for the life of the new IPL, unless the data sets are also used for PLPA 
and/or VIO data sets. 


e From the temporary page activity reference table (TPARTBLE): The system 
uses information from the TPARTBLE on quick starts and warm starts 
(IPLs that do not specify the CLPA parameter). The TPARTBLE contains 
the names of the page data sets used during the previous IPL, at which time J 
the initialization routines wrote the TPARTBLE to the first record of the 
PLPA page data set. On subsequent quick starts or warm starts the informa- 
tion in TPARTBLE is thereby accessible to ASM initialization. 


Note: Two other conditions are prerequisite for certain warm start or quick 
start situations: 


1) The local page data sets from the previous IPL must be mounted for all 
warm starts, to make VIO slots available. Otherwise, ASM forces a quick 
start instead. 


2) The common page data set from the previous IPL must be mounted for 
both quick starts and warm starts if NIP’s writing of the PLPA to the 
PLPA page data set during the previous cold start resulted in spilling some 
of the PLPA records into the common page data set. 


In general, page data sets specified by any means must have been allocated, 
cataloged in the system’s master catalog, and preformatted in VSAM format (with 
track overflow) before an IPL can start. You can format the data sets by using the 
DEFINE PAGESPACE processor of access method services (refer to OS/VS2 
Access Method Services for information about the formatting process). If you 
specify the data sets during sysgen, however, you need not explicitly use the 
DEFINE processor because the DATASET macro uses DEFINE itself to format the 
data sets for you. 


J 


‘For guidance on using the DATASET macro instruction to create page data sets, 
refer to OS/VS2 System Programming Library: System Generation Reference. 
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Syntax Examples for the PAGE Parameter: 


Example 1: The following statements each specify one page data set. 


PAGE=dsname 
PAGE=(dsname) 


Example 2: The following statement specifies three page data sets. 


PAGE=(dsname1 ,dsname2 ,dsname3) 


Dsname! holds the LPA pages, dsname2 holds the common pages, and dsname3 
holds the private area pages. 


Example 3: The following statement specifies n page data sets. 


PAGE=(dsnamel ,dsname2,.. . ,dsname3-n) 


Dsname1! holds the LPA pages, dsname2 holds the common pages, and dsname3 
through dsnamen all hold private area pages. 


Notes: 


1) 


2) 


Hf the operator specifies the PAGE parameter, ASM initialization adds (but 
does not replace) the data sets as specified. IEASYSOO or IEASYSxx are used 
as the first named data sets. To ensure that the operator-specified data sets 
are used for the PLPA and common page data sets, it is necessary to use an 
IEASYSxx member that does not specify page data sets. 


It is unnecessary to specify either UNIT or VOLSER because all page data sets 
must be cataloged. ASM initialization therefore does not need externally 
specified volume serial numbers. The operator may either premount volumes 
or await a mount message. 


Minimum Paging Space: ASM enforces minimum requirements for paging space. 
If the requirements are not satisfied, ASM is forced to terminate the IPL or, later, 
the system. Nevertheless, the use of minimum paging space is inadvisable because 
it can result in poor performance. 


Minimum requirements are as follows: 


@ There must be at least a PLPA, a common, and a local page data set to 


prevent failure of IPL. 


If no duplex page data set is used (the duplex parameter), the PLPA and 
common page data sets must be able to hold the total combination of PLPA 
and common pages. Eight megabytes of space divided between these data 
sets is sufficient as long as no errors occur. If the PLPA and common page 
data sets spill back and forth because of insufficient space, severe 
performance degradation can result. 
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If a duplex page data set is used and is large enough to hold all of the 
PLPA and common pages (the only duplexed areas), the system will be able 
to continue even if the PLPA and common page data sets are full. Neverthe- 
less, this situation is inadvisable because it defeats the purpose of duplexing 
and may severely degrade performance. 


e Local page data sets are used to hold all private area and VIO pages. The 
amount of storage necessary varies with each system and can be calculated 
using the guidelines in “Part 2.1: Auxiliary Storage Management 
Initialization” in this publication. 


Page Space Shortage: Two warning messages appear when the system resources 
manager (SRM) detects a shortage of page space, the first when 70% of the 
available local paging space has been allocated, and the second when 85% has been 
allocated. The SRM reacts to the situation by preventing the creation of new 
address spaces. That is, new “start initiator’’ commands ($SInn), LOGONs, 
MOUNT commands, and START commands for system tasks that execute in their 
own address spaces are therefore ineffective. Upon receipt of these messages, it 
may be possible to add paging space to the system dynamically by using the 
PAGEADD operator command. (Refer to Operator’s Library: VS2 System Com- 
mands for information about using PAGEADD, and to related information about 
the PAGNUM parameter here in this publication.) For these situations, the installa- 
tion should keep some preformatted, cataloged VSAM paging data sets available. 
The data sets can be formatted by using the DEFINE PAGESPACE processor of 
access method services (see OS/VS2 Access Method Services). 


If these data sets are not readily available, it may be possible to modify key 
ASM constants as described in “Part 2.1: Auxiliary Storage Management Initializa- 
tion’. When the page space usage has been decreased below 70% utilization, the 
SRM informs the operator that there is no longer a shortage. 


Value Range: Not applicable. 
Default Value: None. 


Associated Parmlib Member: None. 


Parameter: PAGNUM=(pp,s) 


Meaning and Use: This parameter allows the installation to specify the total 
number of additional page and swap data sets that can be dynamically added to the 
system via the PAGEADD operator command. These numbers represent the total 
number of data sets that can be added during the life of the IPL, regardless of 
whether they are added one at a time or all at once. 


ASM supports as many as 64 page data sets and 25 swap data sets. If the 
number of data sets currently defined to the system and the additional number 
specified by this command exceed these limits, ASM ensures that the maximum 
supported values are not exceeded by truncating the excess specification. One 
should use this parameter with caution because ASM must reserve SQA space for 
each page or swap data set that can be dynamically allocated. 
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How Page Number Values Are Obtained: The PAGNUM parameter is specified in 
one of two sources: 1) IEASYSOO or IEASYSxx, or 2) by the operator-issued 
PAGNUM parameter. An outline of these specifications is as follows: 


e The PAGNUM parameter in IEASYSO0: This page and swap number value 
was specified in the PAGNUM keyword of the CTRLPROG macro during 
system generation. 


e The PAGNUM parameter in IEAS YSxx, an alternate system parameter list: 
If the operator selects this list (by using the SYSP parameter), the PAGNUM 
parameter in IEASYSxx overrides the PAGNUM parameter in IEASYSOO. 


e The PAGNUM parameter specified by the operator in the current IPL: 
This PAGNUM specification overrides the specification in IEASYSOO or 
IEASYSxx. The operator specification lasts only for the life of the IPL. 


Syntax Example for the PAGNUM parameter: 


PAGNUM=(pp;s) 


This specification causes ASM to allow for the addition of pp page data sets and 
5 swap data sets. 


Value Range: Valid pp values are 0-99 so long as the value specified plus the 
number of page data sets specified does not exceed 64. If the combination exceeds 
64, the value used is that which makes a sum of 64 rather than the specified value. 
Valid s values are 0-9 so long as the value specified plus the specified number of 
swap data sets does not exceed 25. If the combination exceeds 25, the value used 
is that which makes a sum of 25. 


Default Value: 1,1. 


Associated Parmlib Member: None. 
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Parameter: PURGE 


Meaning and Use: This parameter specifies that all Mass Storage System (MSS) 
volumes currently mounted for this system are to be demounted. PURGE is 
required when different system configurations have been generated with varying 
numbers of MSS volumes. If the MSS volumes mounted for this system do not 
reflect the exact configuration shown in this system’s UCBs, some volumes may be 
inaccessible to the system. Using PURGE to demount all existing volumes forces 
NIP at I/O initialization to mount the correct volumes for the current system 
configuration. 


Value Range: Not applicable. 
Default Value: None. (If not specified, no MSS volumes are demounted.) 


Associated Parmlib Member: None. 
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Parameter: REAL=nnnn 


Meaning and Use: This parameter specifies the maximum amount of real storage, in 
1K blocks, that can be allocated concurrently for ADDRSPC=REAL jobs. The value 
is rounded to a multiple of 4K bytes. 


The REAL parameter may also be specified in the CTRLPROG macro at 
sysgen. 


Syntax Example: REAL=150 150 + 4 =37-1/2 pages. Rounding to the next 


page boundary yields 38 pages, or a value of 152K. This statement allows up to 
152K (152 x 1024) bytes to be allocated to an ADDRSPC=REAL job. 


Notes: 
1. If possible, avoid a large value for the REAL parameter, since a large value 
degrades system performance, even when no REAL regions are allocated. 
2. If REAL is specified as zero, no ADDRSPC=REAL job will be allowed to 
run. Furthermore, OLTEP will not run, since it requires a REAL region of 
76K. Thus, for all practical purposes, 76 is the minimum REAL value. 


(For storage layouts and general information on real storage usage, refer to 
VS2 Release 2 Storage Estimates. ) 


Value Range: 0-9999.The operand can be from one to four digits. (See Note 2 above.) 
Default Value: 76. (This means a default value of 76K.) 


Associated Parmlib Member: None 
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Parameter: RSU=xx 


Meaning and Use: This parameter specifies the number of processor storage units 
that are required for storage reconfiguration in a multi-processing system. The 
frames in these storage units are not to be used for long-term storage and will be 
designated the non-preferred area. 


During IPL, the operating system assigns the nucleus and V=R areas to the low 
end of storage and assigns the current SQA to the high end of storage. The system 
then defines the reconfigurable storage units starting with the first available (online) 
high end storage unit after the SQA. Offline storage units are skipped during the 
calculation; when they are varied online after IPL they will automatically be 
available for storage reconfiguration. 


After the system has defined the reconfigurable storage units, it defines the 
remainder of the processor storage units as the preferred area for long-term frames. 


Note: While jobs are processing, short-term pages are assigned to any available 
processor storage frames in either non-preferred or preferred areas. Long-term pages 
are assigned only to storage frames in the preferred area. However, when the 
condition occurs that a long-term page requires storage space but the preferred area 
is full, the system performs one of the following: 


e Immediate steal — \f a short-term page that has not been changed is using a 
frame in preferred storage, the system removes the page and assigns the new 
long-term page to the vacated space. 


e Dynamic expansion — If all of the frames in the preferred area are being used 
for pages that are not eligible for ‘‘immediate steal’, the system looks for a 
frame in the non-preferred area. When it finds a frame, it converts the entire 
processor storage unit from non-preferred to preferred. 


Dynamic expansion lowers the number of reconfigurable storage units 
designated by the RSU parameter. Therefore, message IEA988] is issued at the 
system console to inform the system operator. The operator can then issue the 
Display Matrix (D M) command to determine which units are still available 

for reconfiguration. 


Syntax Example: RSU=4. Four storage-units will be available for storage 
reconfiguration. 


Value Range: 0-99. The minimum number of reconfigurable storage units required 
to meet installation subsystem requirements should be specified. If a larger value is 
specified than can be satisfied, the maximum possible is defined without an error 
indication. (See the OS/VS2 Release 3 Guide, GC28-0700, for information on 
determining subsystem requirements.) 


Default Value: 0. If the RSU parameter is omitted or specified as Q, all processor 
storage units are available for preferred storage. 


Associated Parmlib Member: None. 
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Parameter: SMF=xx 

Meaning and Use: This parameter specifies the parmlib member, SMFPRMxx, from 
which SMF will obtain its options. The two alphameric characters, represented by 
XX, are appended to SMFPRM to name the member. NIP saves the name until SMF 
is initialized. 


(For detailed information on SMF parameters, see member SMFPRMxx. For 
suffestions on how to use SMF to supplement the Measurement Facility MF/1, see 
the topic ““How SMF Can Supplement MF/1” in the chapter titled “System 
Performance Factors’’.) 


Value Range: Any two alphameric characters. 


Default Value: 00 (This specifies SMFPRMOO, the IBM-supplied default parmlib 
member. 


Associated Parmlib Member: SMFPRMxx 
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Parameter: SQA=nnn 


Meaning and Use: This parameter specifies to the Virtual Storage Manager the 
maximum size of the virtual system queue area. The virtual system queue area is 
fixed in real storage as it is used. The three digits, represented by nnn, indicate the 
number of 64K blocks (segments) to be added to the system’s minimum virtual 
SQA of 3 segments, or 192K bytes. 


SQA may also be specified by means of the SQA keyword of the CTRLPROG 
macro at sysgen. 


Note: During a Quick Start (i.e., when the CLPA parameter is not specified), NIP 
determines if the currently specified SQA value is equal to the previously specified 
(cold start) value. If it is not, NIP issues an informational message and uses the 
cold-started SQA value. (See the CLPA parameter for a comparison between cold 
start and quick start.) 


Syntax Example: SQA=4 This value indicates to the Virtual Storage Manager 
that its maximum virtual allocation for SQA should be: 192K + (4 x 64K) = 448K. 


SQA Space Shortage: If the Virtual Storage Manager runs completely out of SQA, 
it tries to allocate space from the common service area (CSA). If it can’t obtain 
space from the CSA because the reserved CSA area is too small, it places the system 
in a disabled wait state. To avoid this possibility, the installation should specify 
extra space in the CSA parameter, beyond that obtained from the storage formula. 
(For calculations, storage layouts, and general storage information, see OS/VS2 
System Programming Library: Storage Estimates.) 


The Virtual Storage Manager keeps track of the remaining virtual SQA, and 
informs the System Resources Manager, via a SYSEVENT macro, when the total of 
available virtual SQA plus available virtual CSA has reached two threshold values. 
The two values are currently six pages, or 24K, and two pages, or 8K. The System 
Resources Manager reacts to the situation by issuing an “SQA shortage” message at 
each of the two thresholds. At the upper threshold (24K) it also inhibits the 
creation of new address spaces by disallowing Start Initiator commands ($S Innn), 
LOGON commands, MOUNT commands, and START commands for system tasks 
that require their own address spaces, such as START TCAM or START MF1. 


Value Range: 0—999 (one to three digits) 
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Note: During NIP processing, if a large number of paging data sets have been 
specified via the PAGE= parameter, or if many 2305 paging data sets are active, 

the minimum three segments of SQA may be exhausted before NIP can process the 
SQA= parameter. If this situation occurs, you can change the content of the half- 
word at NVTNVSQA in module IEAVNIPO by means of the AMASPZAP service aid 
(see OS/VS2 System Programming Library: Service Aids, GC28-0674) to reflect 

an increase in the initial SQA allocation. For example, suppose that the content of 
NVTNVSQA is X‘0003’. To add one additional segment of SQA to the initial SQA 
size available to NIP processing, change the NVTNVSQA field content to X‘0004’. 
(If you increase the content of NVTNVSQA, you should correspondingly decrease 
the size represented by the SQA= parameter.) To find the location of the 
NVTNVSQA field, consult listings of the source code or a representation of them on 
microfiche. 


Default Value: | (This means 192K + 64K, or a default size of 256K.) 


Associated Parmlib Member: None 
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VS2.03.807 
IEASYSxx (continued) 
Parameter: SWAP= \ 


dsname 
(dsnamel ,dsname?2 . . .) 


Meaning and Use: This parameter allows the installation to name swap data sets as 
replacements for existing swap data sets for a maximum of 25 swap data sets in all. 
This parameter follows the normal override rules for system parameters. In other 
words, any swap data set specified in a parmlib member IEASYSxx, or specified by 
the operator, completely overrides the previously specified data sets. 


ASM swap data sets are optional. If none are supplied, the LSQA pages 
normally sent to a swap data set will be directed to a local page data set. Similarly, 
if swap data sets become full during system operation, the LSQA pages will be 
directed to a local page data set. Nevertheless, it is advisable for sufficient swap 
space to be always available to ASM to prevent possible performance degradation. 
Additional information and recommendations are in “Part 2.1: Auxiliary Storage 
Management Initialization’’. 


How Swap Data Sets Are Specified: Swap data sets are specified from one of two 
sources: 1) the IEASYSOO or IEASYSxx parmlib member, and 2) the operator- 
issued SWAP parameter. 


@ The SWAP parameter in IEASYSOO — These data set names were specified 
in the SWAPDSN keyword of the DATASET macro during sysgen. 


e The SWAP parameter in IEASYSxx (an alternate system parameter list) — 
If the operator selects this list (by issuing the SYSP parameter), the SWAP 
parameters in IEASYSxx override the SWAP parameter in IEASYSOO. The 
overriding parameters can either increase or decrease the number of data sets 
specified during sysgen. 


@ The SWAP parameter specified by the operator in the current IPL — This 
SWAP parameter specification does not merge with those specified by 
IEASYSxx, as is the case with the PAGE parameter specification, but instead 
overrides those specifications. The operator specification last only for the 
life of the IPL. 


Before an IPL, SWAP data sets specified through SWAP, or through the 
DATASET" macro at sysgen, must have been allocated, cataloged in the system 
master catalog, and preformatted in VSAM format, without track overflow. 
(Unlike page data sets, swap data sets use multi-tracking instead of track overflow.) 
You can use the DEFINE PAGESPACE processor of access method services to 
format the data sets; refer to OS/VS2 Access Method Services for information 
about how to use this processor. For information about using the DATASET 
macro to create swap data sets, refer to OS/VS2 System Programming Library: 
System Generation Reference. 


‘The SWAPDSN keyword of the DATASET macro causes the SWAP parameter 
to be placed in IEASYSOO. 
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VS2.03.807 
JEASYSxx (continued) 


Syntax Examples for the SWAP Parameter 


Example 1: SWAP=dsname 
SWAP=(dsname) 


Either of these statements specifies one swap data set. 


Example 2: SWAP=(dsname1 ,dsname2) 


This statement specifies two swap data sets. 


Example 3: SWAP=(dsnamel ,dsname2, . . . ,dsnamer) 
This statement specifies m swap data sets. 


Note that neither UNIT nor VOLSER is specified. Since all swap data sets must be 
cataloged, ASM initialization does not need externally specified volume serial 
numbers. The operator may either premount volumes or await a mount message. 


Minimum Swap Space: ASM neither checks for a swap data set nor requires a 
minimum size if one is specified. If no swap data set is specified, or if swap data set 
space is exhausted, ASM forces further swap LSQA pages to a local page data set. 
For this reason, one must consider local page data set sizes. 


Swap Space Shortage: If swap data set space becomes unavailable during system 
processing (as evidenced by message ILROO9I, “SWAP DATA SET BAD”’), it may 
be possible to add swap data sets with the PAGEADD operator command. 
Information about PAGEADD is in Operator’s Library: OS/VS2 MVS System 
Commands. Related information is also available here in the /nitialization and 
Tuning Guide under the “PAGNUM Parameter” topic and in “Part 2.1: Auxiliary 
Storage Management Initialization’”’. 


For situations where swap data sets may be added, the installation may keep 
preformatted, cataloged VSAM swap data sets available. 


Value Range: Not applicable. 
Default Value: None. 


Associated Parmlib Member: None. 
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TEAS YSxx (continued) 


= da 
Parameter: SYSP ‘ Gabbe, : 


Note: This parameter may be specified only by the operator. It cannot validly be 
specified in a system parameter list. It is included here for the sake of completeness. 


Meaning and Use: 

The SYSP parameter specifies that one or more alternate system parameter lists 
(e.g. IEASYSO1, IEASYSO2, etc.) are to be read by NIP in addition to the default 
list IEASYSOO. The two alphameric characters, represented by aa, are appended to 


IEASYS to name the alternate list(s). Any number of lists are valid. The 
specification cannot be prohibited by the OPI parameter. 


A system parameter value specified in an operator-selected alternate list 
overrides the value for the same parameter, if it is specified in IEASYSOO. 
(IEASYSOO is always read.) NIP accepts parameters in alternate lists specified in 
SYSP in priority order from right to left. This means that a parameter defined in 
a list specified later in SYSP overrides the same parameter defined in a list specified 
earlier in SYSP. 

Example: 
The operator responds to SPECIFY SYSTEM PARAMETERS by entering: 

ROO, ‘SYSP=(01, 02)’ 


Assume that the two specified members contain the following parameters: 


IEASYSO1: MLPA=(00, 01), BLDL=00, SOA=8 
IEASYSO2: MLPA=02, SQA=10 


NIP would accept MLPA=02, BLDL=00, and SQA=10, in addition to other 
parameters contained in IEASYSQO. 


Value Range: Any two alphameric characters. 


Default Value: 00 (This specifies IEASYSOO.) 


Associated Parmlib Member: [EASYSxx 
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IEASYSxx (continued) 


_ [aa 
Parameter: VAL= | (Ga bbyas: | 


Meaning and Use: This parameter specifies the VATLSTxx member or members of 
parmlib. They are new members in MVS, although similar in function to PRESRES 
in MVT and VS2 Release 1. Volume Attribute Processing reads this member or 
members during Initialization to obtain mount and use attributes for direct access 
volumes. The mount and use attributes are set in the UCBs whose volume serial 
numbers are listed in the VATLSTxx member(s). If multiple members are specified, 
the lists are read in the order in which they appear in the VAL parameter. If a 
particular volume serial number appears on more than one entry, the volume 
attributes specified in the last entry for that volume serial will be accepted. If the 
volume serial does not duplicate another entry, but is for an MSS volume (see the 
‘device type’ parameter in VATLSTxx description), then the last entry with that 
particular MSS unit address will be used to set the volume attributes for the volume. 


(For additional information, refer to the topic that describes the VATLSTxx 
member.) 


Value Range: Any two alphameric characters. 
Default Value: 00 (This means that VATLSTOO, if it exists, will be read.) 


Associated Parmlib Member: VATLSTxx 
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IEASYSxx (continued) 

Parameter: VRREGN=nnnn 

Meaning and Use: This parameter specifies the default real-storage region size for 

an ADDRSPC=REAL job step that does not have a REGION parameter in its JCL. 
The numerical value of the operand (nnnn) indicates the real-storage region size in 1K- 


byte blocks. (VRREGN may also be specified by the CTRLPROG macro at sysgen.) 


Note: The following VRREGN values will prevent an ADDRSPC=REAL job step 
from running if it omits a REGION parameter: 


e VRREGN value that is greater than the value of the REAL parameter, or 
e VRREGN value of zero. 


(For further information on the reserved area of real storage, refer to OS/VS2 
System Programming Library: Storage Estimates. ) 


Value Range: 0—9999 
Default Value: 64 (This means a default REGION size of 64K.) 


Associated Parmlib Member: None 


128 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2 Release 3.7) 


IEASYSxx (continued) 

Parameter: WTOBFRS=nnnn 

Meaning and Use: This parameter specifies the number of buffers that the 
Write-to-Operator (WTO) routines will use for operator system (not JES2) messages. 


The Write-to-Operator buffers are assigned to fixed storage. The parameter was 
formerly a keyword of the SCHEDULR sysgen macro. 


Note: If an insufficient number of buffers are specified, throughput may degrade 
because some messages that need a reply will have to wait for buffers to become 
available. Choose a value significantly higher than 20 (the default) to avoid an early 
wait state soon after IPL. 

Value Range: 20—9999 


Default Value: 20 If the value is less than 20, the specification is ignored, a 
message is issued, and a value of 20 buffers is assigned. 


Associated Parmlib Member: None 
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IEASYSxx (continued) 

Parameter: WTORPLY=nnn 

Meaning and Use: This parameter specifies the number of operator reply elements 
to be used by the Write-to-Operator-with-Reply (WTOR) routines. The reply ele- 
ments are used to queue outstanding replies not yet received from the operator. 
The parameter was formerly the REPLY parameter of the SCHEDULR sysgen 
macro. 

Value Range: 5 — 100 

Default Value: 5 


Associated Parmlib Member: None 
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Member Name: IKJPRM00 


Status 


Changed from MVT and VS2 Release 1. The member formerly contained time 
sharing control parameters, driver parameters, and terminal I/O coordinator (TIOC) 
parameters. It now contains only TIOC parameters. The time-sharing control par- 
ameters and driver parameters need not necessarily be removed, since the TIOC will 
ignore them. However, your system bookkeeping will be simpler, if you delete 
obsolete parameters. 


Use of the Member 


IKJPRMOO is an optional member that contains installation-defined TIOC 
parameters used mainly to control time sharing buffers. The TS and DRIVER para- 
meters, specifiable under MVT and VS2 Release 1, are no longer valid. They are 
now fixed internal parameters of the System Resources Manager. IKJPRMO0 is used 
only during TIOC initialization and does not participate in System Initialization. 


If the installation uses time sharing, the system programmer may optionally 
construct this member by use of the IEBUPDTE utility. (See example of 
IEBUPDTE statements in chapter introduction.) The default values, listed under 
“Internal Parameters” later in this section, are internal constants of the TIOC 
program. You may override a default value by placing the same parameter into the 
member. 


IKJPRMOO, or an alternate member name, may be specified by the operator as 
an optional parameter of the MODIFY tcamproc command. The command starts 
time sharing under MVS. The command syntax consists of: 


MODIFY tcamproc, TS=START [,membername] 


Membername can be either defaulted to IKJPRMOO, or specified as the name of 
an installation-defined alternate. If the operator omits the member name, the sys- 
tem looks for member IKJPRMOO when time sharing is started. (For additional 
information on the use of the MODIFY tcamproc command, see Operator’s 
Library: OS/VS2 Reference (JES2) and Operator’s Library: OS/VS2 TCAM.) 


TIOC Initialization tries to obtain parameters by reading the specified parmlib 
member. Special processing occurs if errors are encountered. If parmlib can’t be 
allocated or opened, an information message is issued, and default parameters are 
used.* If the specified member can’t be found in parmlib, another message is 
issued and TIOC Initialization terminates. In this case, the operator should reenter 
the MODIFY tcamproc command, either specifying the correct member name or 
omitting the member name. If the name is omitted, TIOC Initialization tries to 
read IKJPRMOO. If it can’t locate IKJPRMO0, or encounters an I/O error in reading 
the explicit or default member, it uses the default parameters.* If TIOC Initializa- 
tion encounters an invalid parameter, which is not correctly specified in a later 
entry, it uses the default value.* Unsupported parameters, if retained from a 
previous version of IKJPRMOO, are ignored. 


“See “IBM Supplied Defaults” later in this section. 
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IKJPRMOO (continued) 


Parameter in IEASYSxx: None 
(or specified by the operator) 


Syntax Rules 


The following rules apply to the creation of IKJPRMOO by means of the IEBUPDTE 
utility: 


e Each record must start with the word TIOC, followed by a blank. 


e For each record, columns one through 71 are valid for data. Columns 72 
through 80 are ignored. 


e A parameter must be complete in a record. It may not cross record 
boundaries. The parameter, however, may be repeated. 


e When a parameter is specified more than once in the member, the last 
occurrence is accepted. 


e You may use either a blank or a comma as a Separator between adjacent 
keywords. 


e Invalid or misspelled parameters are ignored. Defaults are substituted, and 
an informational message is issued to the operator. 


IBM-Supplied Defaults 


The default values are internal constants in the TIOC program. Those that were in 
effect for MVT and VS2 Release 1 have been changed, and are now the following: 


BUFSIZE=64, BUFFERS=6*USERMAX, USERMAX=number of time- 
sharing terminals! + 10%, OWAITHI=20, OWAITLO=4, INLOCKHI=4, 


INLOCKLO=1, RESVBUF=BUFFERS/10, RECONLIM=0 


Internal Parameters 


Two parameters valid in MVT and VS2 Release 1 have been removed, and two new 
parameters have been added to IKJPRMOO. The two removed parameters are 
USERCHG and SLACK. If either parameter is specified, the TIOC will ignore the 
parameter. The two new parameters are USERMAX and RECONLIM. They are 
described in the following tabulation. 


I The number of time sharing terminals is the number of TCAM terminals 
defined as usable for time-sharing. (See OS/VS2 TCAM Programmer’s Guide for 
information on defining terminals for time-sharing.) 
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Parameter 
BUFSIZE 


BUFFERS 


INLOCKHI 


INLOCKLO 


OWAITHI 





IKJPRMOO (continued) 


Meaning and Use 


Specifies the storage size of a TIOC buffer. 


Specifies the number of buffers in the TIOC buffer 
pool. (See note below.) 


Specifies the number of TIOC buffers to be allocated 

to a terminal user for input before his keyboard is locked. 
This is not an exact lock but works on an input line basis. 
If the number of buffers used to input one or more lines 
exceeds the INLOCKHI value, the keyboard remains 
locked until all of these conditions are satisfied: the user 
is swapped in, part or all of the input is removed (the 
TGET is satisfied), and the number of allocated buffers 

is reduced to or below the INLOCKLO value. 


INLOCKHI must be large enough to permit the largest 
possible legitimate input message sent from any terminal 
in your system to be received by TIOC. Any input 
message larger than BUFSIZE times INLOCKHI will be 
canceled and will cause an error message at the terminal. 


Note: If the terminal is defined as “NO BREAK” (in 
the TERMINAL command or TCAM message control 
program), the INLOCKHI value is inconsequential, since 
the keyboard in this case is unlocked only when a 
demand for input occurs (i.e., when a TGET is issued). 


Specifies a low threshold of allocated input buffers. 
When the number of allocated input buffers is 
reduced to or below this number, the user’s 
keyboard is unlocked. 


Note: If the terminal is defined as “NO BREAK”’, 
the INLOCKLO value is inconsequential. (See Note 
for INLOCKHI.) 


Specifies the maximum number of output buffers 
that can be allocated to a terminal. When that num- 
ber is reached, the user’s address space is placed in 
output wait and is swapped out of real storage. 


Note: If your installation uses the 3270 terminal, 
specify enough buffers to completely fill the screen. 
You may compute this number of buffers from the 
formula: 


Buffers = (message length + 6) + (BUFFERSIZE - 6) 


If there are not enough buffers for a “full screen 
write,” the address space will be put into output 
wait and swapped out until buffers become 
available. 





Value 

Range Default Value 

20 - 252 64 

4-32,767 — six times the 
USERMAX value 

1 - 32,767 4 

less than ] 

INLOCKHI 

and BUFFERS 

1 - 32,767 20 
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Parameter 


OWAITLO 


RECONLIM 


RESVBUF 


USERMAX 


IKJPRMOO (continued) 


Meaning and Use 


Specifies a low threshold value for the number of 
allocated output buffers. When the number of output 
buffers reaches this value, the System Resource 
Manager is notified that the terminal user’s job 

can be swapped into storage and allowed to 

execute. 


Specifies the time limit in minutes within which a 
user may reconnect after his TP line has been 
disconnected. 


Specifies the minimum number of free buffers that 
are available. Its purpose is to maintain a reserve 
of free buffers that can handle output without 
“bottlenecking” the system. If the number of 

free buffers falls below this value, all terminals 

are locked for input, regardless of INLOCKHI 
value. The terminals will be unlocked when the 
number of free buffers becomes equal to 
RESVBUF. 


Specifies the maximum number of time-sharing 
users that may be logged on. 


Value 
Range 


less than 
OWAITHI 
and 
BUFFERS 


0 - 32,767 


Default Value 


4 


1 — value of 10% of the number 


BUFFERS 


1 - 32,767 
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of buffers specified 
in BUFFERS 
parameter. 


Total number of 
terminals that 
support time sharing 
+10%. (Note: The 
number of terminals 
that support time 
sharing is specified in 
the TCAM Message 
Control Program.) 
(See OS/VS2 TCAM 
Programmer's Guide. ) 


Member Name: IRBMF1xx 
Status 
New for MVS. This member did not exist in MVT or VS2 Release 1. 
Use of the Member 


IRBMF 1xx is used to control the functioning of the System Activity 
Measurement Facility (MF/1). See the chapter entitled ‘““How to Use the System 
Activity Measurement Facility (MF/1)’. 


MF/1 control options can be specified by the operator in the START command 
‘parmvalue’ field, or be specified in the PARM field of the EXEC statement in the 
MF/1 cataloged procedure, or in the IRBMF1xx library member. Combinations of 
these sources are possible. Parameters specified in the START command override 
any conflicting specifications in either the EXEC statement or in the library mem- 
ber. Parameters which have not been specified in the START command can take 
values from parameters in the EXEC statement or library member. Parameters which 
have been specified in neither the START command nor the EXEC statement can 
take values from specifications in the library member. Finally, parameters not 
specified in any of these three sources use program default values. 


If mutually exclusive parameters (e.g., CPU/NOCPU) are specified within one of 
the three option sources, the last specification will override and the operator will 
receive the message ‘IRB3011 INVALID OR MUTUALLY EXCLUSIVE OPTIONS 
APPEAR IN MF/1 [OPERATOR] [PARM] [LIBRARY] INPUT”. If, however, 
conflicting specifications occur within different option sources, the higher priority 
source will override, and no message will be issued. 


The foregoing message will also be issued if a parameter contains an invalid 
value (for example, if ‘CYCLE(10)’ is specified). If the source in error is the EXEC 
statement or the library member, the values of these parameters will be listed. The 
listing includes the last specification in the case of a conflict, or a default in the 
case of an invalid value. If the option source in error is the START command, the 
operator is given the opportunity to either re-enter the START command options, 
or to ignore the START command as an option source. 


If an option source contains a syntax error, the operator receives the message 
‘IRB300I1 MF/1 SYNTAX ERROR IN OR FOLLOWING TEXT BEGINNING 
“XXXXXXXXX’ IN [OPERATOR] [PARM] [LIBRARY] INPUT’. As with 
invalid values, the options are listed. In the case of options from the START com- 
mand, the operator is able to make immediate changes or ignore the option source. 


If after all controlling options have been gathered, a logical inconsistency is 
detected in differing options (for example, the specified STOP value is less than the 
INTERVAL value), the following message is issued: ‘IRB301] INVALID VALUES 
OR MUTUALLY EXCLUSIVE OPTIONS APPEAR IN MF/1 INPUT’. 
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IRBMF1xx (continued) ) 


If any of the above messages are issued during MF/1 option determination, and 
the operator has not yet been given the opportunity to change the controlling 
options, (or if the ‘OPTIONS’ parameter was specified), all options are listed. After 
the options are listed, the message ‘IRB306D REPLY WITH MF/1 OPTIONS OR 
GO’ is printed, and the operator has the opportunity to change any options. 
Exception: He cannot now give another value for the MEMBER parameter, since 
no further library member scan will be made. If further errors occur in the opera- 
tor’s input, a sequence similar to the above will follow, except that ‘REPLY’ 
rather than ‘OPERATOR’, ‘PARM’, or ‘LIBRARY’ will be listed as the source of 
the error. 


If the selected options consist of ‘NOCPU’, ‘“NOPAGING’, ‘NOCHAN’, 
‘NOWKLD’ and ‘NODEVICE’ (indicating that no MF/1 measurements are to be 
collected), the message ‘IRB202I NO MF/1 MEASUREMENTS SELECTED’ will be 
issued, and MF/1 execution will be terminated. 


Parameter in IEASYSxx: None 
(or issued by the operator) 


Syntax Rules 


e MF/1 control options are taken from the library data set as 80-byte card 
images. Valid data may be placed in columns 1 through 72. Columns 73 


through 80 will be ignored. ) | 


e MF/1 options may appear in any order, separated by commas, blanks, or 
comments (in the form /* text */). Additional blanks are ignored, and they 
may appear anywhere except within option keywords. Comments may 
appear anywhere that blanks appear. 


IBM-Supplied Defaults 


The following values are in the IBM-supplied PARMLIB member IRBMF100. They 
are also the internal program default values. (See “Internal Parameters” for the 
meaning of these parameters): 


CPU 

CHAN 

DEVICE (CHRDR, COMM, DASD, GRAPH, TAPE, UNITR) 

PAGING 

WKLD (PERIOD) 

CYCLE (250) 

INTERVAL (15M) 

MEMBER (00) 
(This is a program default only. This parameter does not occur in IRBMF100, 
since a member name cannot be specified within a library member.) 

OPTIONS 

NORECORD 

REPORT (DEFER) 


STOP (15M) 
SYSOUT (A) a 
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IRBMF1 xx (continued) 


Internal Parameters 


Parameter 


| 
| 
| 


| 


| 


CPU 
NOCPU 


CHAN 
NOCHAN 


| 


DEVICE (device list) 


NODEVICE 


PAGING 


NOPAGING 
(PERIOD) 

WKLD } (GROUP) 
(SYSTEM) 


NOWKLD 


CYCLE (value) 


INTERVAL 


(Value) 
(Value M) 


| 


| 


| 


| 


Meaning and Use 


Specifies whether system CPU activity is to be monitored 
by MF/1. 

Specifies whether system channel activity is to be 
monitored by MF/1. 

Specifies whether system device activity is to be 
monitored by MF/1. If device activity is to be monitored 
(DEVICE specified), a device list indicates the classes of 
devices that will be monitored. When the DEVICE 
parameter is specified, a device list must be included. 


Device List Members: 





| CHRDR Character reader devices. 
NOCHRDR 
COMM Communications equipment. 
NOCOMM 
DASD Direct access storage devices. 
NODASD 
GRAPH Graphics devices. 
NOGRAPH 
| TAPE Magnetic tape devices. 
NOTAPE 
UNITR Unit record devices. 
NOUNITR 


Specifies whether system paging activity is to be 
monitored by MF/1. 


Specifies whether system workload activity is to be 
monitored by MF/1. If workload activity is to be 
monitored (WKLD specified), the level of detail of the 
report to be produced must be specified. PERIOD 
requests the most detailed level by performance group 
period; GROUP requests reporting by performance 
group; SYSTEM requests a system summary report. 
Specifies the frequency at which sampling observations 
are to be made of channel and device data. The range is 


from 50 to 999 milliseconds. The default is 250 
milliseconds. 


Specifies the interval at which all data will be gathered 
for report formatting and/or SMF record writing. The 
range is from 1 to 60 minutes. The default is 15M. 


Part 2: System Initialization - PARMLIB Members 137 


IRBMF1 xx (continued) 


Parameter Meaning and Use 2 


MEMBER (nn) The value specified by this parameter is appended to 
IRBMF1 to form the name of the partitioned data set 
member that contains the MF/1 options. This parameter 
may be specified in the PARM field of the START com- 
mand or EXEC statement, but should not be specified 
within a partitioned data set member. The default is 00, 
indicating member IRBMF100 in SYS! .PARMLIB. 


OPTIONS or OPTN Specifies whether or not a list of the options to be used 

NOOPTIONS or will be printed at the operator’s console at MF/1 

NOOPTN initialization. If the list is printed (OPTIONS or OPTN 
is specified), the operator will be able to respond with 
any desired changes to the option list. 


Note: To avoid unnecessary console output and a delay 
in activating MF/1, specify NOOPTIONS. If any syntax 
errors are defected by MF/1, OPTIONS will be forced. 


| RECORD Specifies whether monitored data is to be written to the 

NORECORD SMF data set. If SMF records are to be written, SMF 
data recording must have been specified at IPL as 
MAN=ALL. 


| REPORT loses) Specifies whether or not printed reports of the 
———= (DEFER) monitored data are to be produced. If the reports 
NOREPORT are to be produced (REPORT is specified), the J 
REALTIME/DEFER options specify whether the 
reports are to be printed when formatted at the 
conclusion of a data gathering interval (REAL- 
TIME is specified), or printed after MF/1 
processing ends (DEFER is specified). 


STOP 


(value H) minutes or hours. The range is from one minute to one 
(value M) week (168 hours or 10,080 minutes). The units default 
NOSTOP is M (minutes). The default value is 15M. The operator 
STOP command can terminate execution at any time, 
regardless of the value for this parameter. 


SYSOUT (class) Specifies the SYSOUT class to which formatted reports 
are directed. Class A is the default. 


| (value) ! Specifies the desired time duration for MF/! activity in 
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Member Name: LNKLSTxx (Link Library List) 


Status 


A single member, LNKLSTOO, existed in MVT and VS2 Release 1. The current 
multi-member option was new in VS2 Release 2. 


Use of the Member 


LNKLSTxx contains the names of program libraries on multiple volumes that are 
to be concatenated to SYS1.LINKLIB. The default member LNKLSTOO, built at 
sysgen, contains only the name SYS1.LINKLIB. The installation may add other 
library names to LNKLSTOO through use of the IEBUPDTE utility. 


You can set up any number of LNKLSTxx members, although no more than 
15 libraries may be concatenated to LINKLIB in the life of a single IPL. Each lib- 
rary can have up to 16 extents. NIP opens and concatenates each library in the 
order in which library names are listed, starting with the first-specified LNKLSTxx 
member. If the total number of libraries (excluding LINKLIB) exceeds 15, only the 
first 15 are used and a warning message is issued. 


Notes: Any library listed in LNKLSTOO or LNKLSTxx is automatically authorized, 
since LINKLIB is authorized. LNKLST-named libraries must be cataloged in the 
system master catalog. (OS CVOLs are not searched for LNKLST-named libraries 
at IPL.) 


aa 
Parameter in IEASYSxx: LNK= fore ek ; 
(or specified by the operator) 


The two alphameric characters, represented by aa, are appended to LNKLST to 
identify one or more LNKLSTxx members of parmlib. If the parameter is not 
specified either in IEASYSxx or by the operator, the default member LNKLSTOO 
is used. 


Syntax Rules 


The following rules apply to the creation of LNKLSTxx by means of the 
IEBUPDTE utility: 


@ Place on each record a string of data set names separated by commas. 


e Indicate continuation by placing a comma followed by at least one blank 
after the last name on a record. 


@ Make sure that the total number of data sets, excluding LINKLIB, 
contained in all the specified LNKLST members doesn’t exceed 15. Other- 
wise, a message is issued, and only the first 15 named data sets are 
concatenated. 


e If you place the name SYS1.LINKLIB on any record in any LNKLST 
member, the name will be ignored. 
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LNKLSTxx (continued) 


e Be careful not to specify the same library name more than once in a succession J 
of LNKLSTxx members. The same library will be concatenated as many times 
as it appears in all specified LNKLST members. The result can be slowed 
performance, since the same library can be searched two or more times for a 
module that resides there. 


Syntax Example 
IEASYSxx: ... LLNK=(00,01,02,03) 
LNKLSTOO: DOG,FOX,EASY,KING,JOG,BOBBY 
LNKLSTO1: PETER,QUEEN,MIKE 
LNKLSTO2: GEORGE,BAKER,ABLE 
LNKLSTO3: DATA1,DATA2,DATA3 


The result of the foregoing specification is that the following data sets are 
concatenated to SYS1.LINKLIB: 


DOG,FOX,EASY,KING,JOG,BOBBY,PETER,QUEEN,MIKE,GEORGE, 
BAKER,ABLE,DATA1,DATA2, and DATAS. 


IBM-Supplied Defaults 


Default member LNKLSTOO contains only the name SYS1.LINKLIB. 


Internal Parameters: Not applicable | ) 
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Member Name: MVIKEYO00 


Status 


A new member for VS2 Release 3 that is provided for the Mass Storage System 
(MSS). MVIKEY0O0 is automatically built at sysgen, but it can be altered at any time 
by means of the IEBUPDTE utility. 


Use of the Member 


MVIKEY0O0 supplies three parameters to the Mass Storage System Communicator 
(MSSC) that define the names of the mass storage volume Inventory and volume 
control Journal data sets, where the space manager messages are to be written, and 
how often to check the Staging Drive Table for balancing the staging drive groups. 


Parameter in IEASYSxx: None 
(or specified by the operator) 


Syntax Rules 
The following rules apply when MVIKEY0OO0 is updated with the IEBUPDTE utility: 


e@ Use columns one through 71. Do not use columns 72-80, since these columns 
are ignored. 


e Avoid embedded blanks. 
@ Separate consecutive parameters by a comma. 
e Do not divide a parameter between consecutive records. 


e Indicate continuation by a comma followed by one or more blanks after the 
last entry on a record. 


Syntax Examples 


MSVCCAT=MSVICAT ,MSSCSAMP=02,MSFMSG-02 
MSVCCAT=USE RCAT 1,MSFMSG=(05,JOURNAL) 


IBM-Supplied Defaults 
The following defaults are automatically placed in MVIKEYO0 at sysgen: 


MSVCCAT=MSVICAT,MSSCSAMP=03,MSF MSG=JOURNAL 
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MVIKEY00 (continued) ) 
Internal Parameters 
The following parameters are all optional and can be coded in any order. 


Value 
Parameter Meaning and Use Range Default Value 


XX 
MSFMSG= < JOURNAL Specifies where the space manager messages 01-16 JOURNAL 
xx,JOURNAL ) regarding the volume inventory status are 

to be written. xx identifies the route code 

of the alternate console where they will be 

written. JOURNAL specifies that the 

Journal data set is to be used to record 

these messages. However, if the Journal 

data set fills up, subsequent messages are 

lost unless they are also directed toa 

console. 


MSSCSAMP= 4 a \ Specifies how often the MSSC will sample 00-99 03 
= the load on each of the staging drive minutes 
groups. The MSSC determines the least 
and most-used groups and passes this 
information to Device Allocation so Device : 
Allocation can best choose a 3330V unit J 
when it must mount a new MSS volume. 


Specifies the high qualifier name of the 1-8 MSVICAT 
volume Inventory and volume control alphameric 

Journal data sets. The Journal data set characters* 

must be identified in the (Master or user) 

VSAM Catalog as xxxxxxxx.MSVCJRNL 

and the Inventory data set must be identi- 

fied as xxxxxxxx.MSVI. If a VSAM user 

catalog is used, then the name of this user 

catalog must be xxxxxxxx. 


_ § XXXXXXXX 
MSVCCAT= { NBVIE ree 





*First character must be alphabetic or national. Following characters can be J 
alphameric or national (including the hyphen and 12/0 overpunch). 
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Parameter 


MSVCCAT (continued) 


MVIKEY00 (continued) 


Value 
Meaning and Use Range Default Value 


The Inventory data set defaults to 
MSVICAT.MSVI and the Journal data set 
defaults to MSVICAT.MSVCJRNL both 
cataloged in the VSAM Master Catalog 

or the VSAM user catalog MSVICAT. 
MSVICAT is automatically generated in 
the MSS logic at sysgen. 


Note: In an MP system, the Journal and 
Inventory data sets and the user catalog 
where they are cataloged must reside 
permanently on shared DASD. (For 
information on creating the Inventory 
and Journal data sets, see OS/VS Mass 
Storage System (MSS) Services for 
Space Management. ) 


Part 2: System Initialization - PARMLIB Members 


143 


Member Name: PARMTZ ; 
Status: Introduced in VS2 Release 1. 


Use of the Member 


PARMTZ contains the time zone constant — the value in hours, minutes, and 
seconds by which the local time differs from Greenwich Mean Time (GMT), and the 
direction, east or west, from Greenwich. Time-of-Day Clock Management uses the 
time zone constant to calculate local time. 


The time zone constant can be set (and placed in the CVT) at either sysgen or 
Initialization. At sysgen, the constant is set in the CVTTZ field of the CVT via the 
TZ keyword of the CTRLPROG macro. 


The time zone constant can be overridden by adding a PARMTZ member to 
PARMLIB via the IEBUPDTE utility. At Initialization, if PARMTZ can be read, the 
PARMTZ value is placed in CVTTZ. 


The time zone constant defaults to that specified at sysgen if: 


e The value in PARMTZ is invalid, or 
e There is no PARMTZ member, or 
e The member cannot be read. 


If no time zone constant is specified at sysgen and no PARMTZ member exists, or it ) 
can't be read, atime zone constant of zero is placed in the CVTTZ field of the CVT. 


The operator can change the time-of-day clock by responding to a system 
message at Initialization (if such messages are not suppressed by the TOD keyword 
in COMMNDxx). Only local time can be changed after an IPL, by means of the 
SET command. The TOD clock remains unchanged. (See Operator’s Library: 
OS/VS2 Reference (JES2) for information on setting local time.) 


Operator responses at Initialization can be minimized if you specify TOD= 
NOPROMPT in the COMMNDxx member of parmlib. This keyword will cause the 
TOD clock verification messages to be suppressed. In spite of this suppression, 
however, the operator will be prompted in either of two cases: 


e The TOD clock has not been set, or 


e Multiple TOD clocks (in a multiprocessing configuration) are not 
synchronized. 


Parameter in IEASYSxx: None 
(or entered by the operator) 
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Parameter 
E 


HH 


SS 


PARMTZ (continued) 


Syntax Rules 


The following rules apply to the creation of PARMTZ by means of the IEBUPDTE 
utility: 


@ The member consists of one record (see examples that follow). 
@ The member uses the following syntax, whose parameters are explained in 


“Internal Parameters’’. 


at HHLMML[SS]] 


Syntax Examples 
E,01.48.32 


W,11 
W,10.00.59 


IBM-Supplied Defaults 


No default parmlib member. However, the time zone constant defaults to the 
sysgen-specified value or to zero if no value was specified at sysgen. 


Internal Parameters 


Value 
Meaning and Use Range Default Value 

Specifies a time zone east of Greenwich Mean Not None 

Time (GMT). applicable 

Specifies a time zone west of Greenwich Mean Not None 

Time (GMT). applicable 

Specifies the number of hours deviation from GMT. 00—12 None 
Specifies the number of minutes. This is an optional 00—59 None 
parameter. 

Specifies the number of seconds. This is an optional 00-59 None 


parameter which is valid only if minutes (MM) is 
specified. 
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Member Name: SMFPRMxx 





Status 


A new member name replaces SMFDEFLT that was used in MVT and VS2 
Release 1, Separate foreground options will no longer be specified, since foreground 
and background options are now the same. 


Use of the Member 


SMFPRMxx contains parameters that define how the SMF facility will be used. The 
parameters are of two types, required and optional. The required parameters specify 
the job wait time limit and the system on which SMF is active. Optional parameters 
allow you to select record types, specify physical information about the data sets, 
permit operator modification, and specify whether exits are to be taken. NIP itself 
does not use the parameters. It passes the member name to Master Scheduler 
Initialization for use in SMF initialization. 


Note: The SYS1.MANX and SYS1.MANY data sets must be cataloged on DASD. 
This is a new requirement. If they are not, the Master Scheduler will fail during 
Initialization. (For a full discussion of SMF requirements and usage, refer to 
OS/VS System Management Facilities (SMF). ) 


Parameter in IEASYSxx: SMF=xx 
(or specified by the operator) ‘ 
) 


The two alphameric characters, represented by xx, are appended to SMFPRM to 
identify the SMFPRMxx member of parmlib. If the parameter is not specified 
either in IEASYSxx or by the operator, the default member SMFPRMOO is used. 


Syntax Rules 


The following rules apply to the creation of SMFPRMxx by means of the 
IEBUPDTE utility: 


e Use columns one through 71. Do not use columns 72—80, since these 

columns are ignored. 

Avoid embedded blanks. 

Separate consecutive parameters by comma. 

Enter each parameter in the format: keyword=value. 

Place each parameter completely on a record. That is, do not divide a 

parameter between consecutive records. 

e Indicate continuation by placing a comma after the last entry on a record, 
followed by a blank before column 72. 


Syntax Example 


OPT=2,EXT=YES,BUF=4096,SID=A158, 
JWT=15,OPI=YES,MAN=ALL 
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Parameter 
JWT=nnn 


SID=xxxx 


~| 


NONE 
USER 
ALL 


| 


SMFPRMxx (continued) 

IBM-Supplied Defaults 

Sysgen places the following parameters into the default member, SMFPRMOO: 
OPT=2,EXT=YES,JWT=10,BUF=2000,SID=H155,OPI=YES,MAN=ALL 


You should modify this list according to your system requirements. You may place 
alternate values, plus additional values, in one or more alternate SMFPRMxx lists. 


Note: You should add DSV=2 or 3 to the default list (or to an alternate list) if you 
intend to use the IEHUCAT utility to update your OS catalogs for use with MVT or 
VS2 Release 1. 


Internal Parameters 


SMF parameters valid for MVS are described in the following table. Three 
previously valid parameters not shown in the table have been deleted: MDL, PRM, 
and ALT. The MDL parameter has been combined with the SID parameter. The 
PRM and ALT parameters, which formerly specified the volume or device for 
SYS1.MANX and SYS1.MANY, are no longer needed. (The SMF data sets must 
now be cataloged on direct access.) 


Value 

Meaning and Use Range Default Value 
This is a required parameter that initially specifies 1—999 10 
the number of minutes a job is allowed to wait 
continuously. When the specified time limit has 
expired, the time limit exit routine (IEFUTL) is 
entered, if exits are to be taken. The limit value 
can be changed by IEFUTL. 
This required parameter does what SID and MDL four H155 (Wote: This is not 
did in VS2 Release 1 and MVT. It specifies alphameric =a typographical error.) 
the system and model on which SMF is active, and/or special 
provided the installation modifies the default value. characters 
This “optional” parameter specifies the type of not ALL 
records to be written to the SMF data set(s), applicable 


Note: If MAN=ALL or USER, the BUF parameter is 
also required, and must not be zero or defaulted. 


NONE 


specifies that no records are to be written to 
the SMF data set(s), regardless of values 
specified for OPT, DSV, and REC 
parameters. 


USER 


specifies that only user records (types 128 
through 255) are to be written to the SMF 
data set(s). 
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SMFPRMx<x (continued) 





Value 
Parameter Meaning and Use Range Default Value 


ALL 
MAN= specifies that both SMF-produced and 
(continued) user-produced records are to be written to the 
SMF data set(s). All SMF records are created 
unless suppressed by the OPT, DSV, or REC 
parameters. 


Note: ALL should be specified if you intend to run 
the IEHUCAT utility to update OS catalogs. 


This “optional”’ parameter specifies whether system 1—2 2 
and job information, as opposed to system, job, and 
job step information, is to be recorded. 


IN 


} specifies that only system and job-related 
information is to be collected by SMF. The 
step-initiation exit, IEFUSI, and the job step 
termination exit IEFACTRT are not taken. 


specifies that system, job, and job step 
information is to be collected by SMF. 


Notes: J 


1. If you wish the System Resource Manager to do 
I/O load balancing, you must specify OPT=2 so 
that the System Resource Manager can access 
EXCP counts by job step. OPT=2 is also 
necessary if you wish to run the IEHUCAT 
utility to update OS catalogs. 


2. If OPT=1 is specified, and the DSV=2 or DSV=3 is 
also specified, SMF converts OPT=1 into OPT=2 
and issues a warning message. 


This “optional” parameter specifies whether dataset 0-3 0 
information and/or direct access volume information 
is to be collected by SMF. 


0 


DSV= 


WwnNnre fo 


specifies that neither data set information nor 
direct access volume information is to be 
collected. 


specifies that direct access volume information is 
to be collected and data set information is to be 
suppressed. 


collected and direct access volume information 


specifies that data set information is to be , 
to be suppressed. - 
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Parameter 


DSV = 
(continued) 


REC= 


BUF= 


| 


NO 
— 


nnn 
nnnn 


| 


SMFPRMxx (continued) 


Meaning and Use 


specifies that both data set information and 


direct access volume information are to be 
collected. 


Notes: 


1. You should specify DSV=2 or 3 if you plan to 
use the IEHUCAT utility to update your 


catalog for use with MVT or VS2 Relea 


2. If either DSV=2 or DSV=3 is specified and 


OPT=1 is also specified, SMF converts 


OPT=1 into OPT=2 and issues a warning 


message. 


This optional parameter specifies whether rec 


Value 
Range 
se l. 
ord O or 2 


type 17 will be written for temporary data sets. The 


parameter is not effective unless DSV is also 
specified as 2 or 3. 


0 


specifies that record type 17 is to be written 
for non-temporary data sets only, and information 
is to be suppressed for temporary data sets. 


specifies that record type 17 is to be written for 
both temporary and non-temporary data sets. 


This parameter specifies the size of the SMF buffer. 400 to 
It must be specified in the MAN parameter equals 8,192 


ALL or USER. 


Notes: 


1. You should specify a value that is a multiple of 
8 bytes (double word). Otherwise, SMF rounds 


the value to the next lower multiple of 


8 bytes. 


2. Before you reduce the buffer size specified in 
the previous IPL, you must dump the SMF 
data set(s). Otherwise, the data set(s) cannot 


be dumped. 


Default Value 


None 

(No default value exists. 
Operator is prompted if 
nonzero BUF value is 
needed and was not 
specified.) 
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SMFPRMxx (continued) 


Value 
Parameter Meaning and Use Range Default Value 


YES \ This optional parameter specifies whether the Not NO 
NO SMFPRMxx parameters are to be presented on applicable 

the console during IPL for the operator’s 

inspection and/or modification. 


YES 
specifies that the operator is allowed to modify 
parameters. 


NO 
specifies that the operator is not allowed to 
modify parameters. 


opt= { 


YES This optional parameter specifies whether SMF Not YES 
exits are to be taken. The parameter is applicable 
independent of the value specified for MAN. 


YES 
specifies that exits are to be taken. 


NO 
specifies that exits are not to be taken. 


Note: If EXT is specified as YES, the exits taken will 
depend on the data collection parameter OPT. If 
OPT=2, all exits defined for the system will be taken. 
If OPT=1, however, the job step initiation exit and 
the job step termination exit will not be taken. 
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Member Name: VATLSTxx (Volume Attribute List) 


Status 


This member in MVT and VS2 Release 1 was called PRESRES. It was read during 
Master Scheduler Initialization. In MVS, it is read during general NIP processing. 
Principal changes from previous usage are as follows: 


e Multiple members of the name VATLSTxx are supported. 
e The format of a VATLSTxx entry differs from that of a PRESRES entry. 
e Informational messages are issued only when errors are detected. 


Use of the Member 


VATLSTxx member(s) contain the volume attribute list(s) that predefine the 
“mount” and “use” attributes of direct access volumes. The Volume Attribute 
Processor reads the volume attribute list(s) in order to set ““mount”’ and “use” status 
bits in direct access UCBs*. 


The system programmer can predefine volume “‘mount” attributes as 
permanently resident or reserved, and can predefine volume “use”’ attributes as 
storage, public, or private. Critical direct access volumes can thus be controlled, 
since the “mount” and “use” attributes determine the type of data sets that can be 
placed on a volume. Data sets on volumes marked permanently resident or reserved 
receive preferential treatment during allocation. (See “Device Allocation” in 
“System Performance Factors” chapter.) 


You can ensure a faster initialization by efficiently specifying the volume 
attribute list(s). Do not specify a list at a given IPL that contains entries for volumes 
that will not be mounted. Unmounted volumes require operator intervention with 
resultant delay. 


Use of 3344 and 3350 Emulated 3330-1 and 3330-11 Devices 


The category of devices consisting of the 3344 emulated 3340 and the 3350 
emulated 3330-1 and 3330-11 must be made permanently resident via the VATLST 
facility because of a conflict in mount states. Because these emulated devices 
cannot be demounted as can their real counterparts, the mount and demount 
messages that the Operating system ordinarily issues for the real devices are 
erroneous. To prevent these erroneous messages, you must mark the emulated 
devices as permanently resident by so noting them in their respective VATLST 
entries. 


Also, take care to ensure that all emulated devices necessary for a given IPL are 
ready and available (not held in reserve by another CPU) at IPL time. Specifically, if 
another CPU has an emulated device reserved at IPL time, the operator must reply 
“WAIT” to the message “IEAIZ0A DEVICE ddd SHARED. REPLY ‘CONT’ 

OR ‘WAIT’ ”. 


**Mount”’ attributes are set in the UCBSTAT field, status byte A (offset 03) in the 
UCB. “Use” attributes are set in the UCBSTAB field, status byte B (offset 34 
decimal, 22 hex) in the UCB. 
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VATLSTxx (continued) 
Definitions of the Mount and Use Attributes 


The mount attribute determines the conditions under which a volume can be 
demounted. There are three ‘“‘mount” attributes: permanently resident, reserved, 
and removable. The permanently resident or reserved attributes may be specified in 
a volume attribute list. The removable attribute automatically applies to any volume 
that VATLSTxx does not designate or default as permanently resident or reserved. 


A permanently resident volume is one that either can’t be physically demounted 
(e.g., a drum, 3344, 3350), or can’t be demounted until its device is varied offline. 
Only direct access volumes can be made permanently resident. The following 
volumes are always marked permanently resident by NIP. You should therefore 
specify only the use attribute of these volumes in a volume attribute list: 


e Volumes that can’t be physically demounted (e.g., a 2305 or 3350 volume). 

@ The system residence vdlume. This includes the SYS1.LOGREC, SYS1.SVCLIB, 
SYS1.NUCLEUS data sets. 

e@ Volumes that contain these system data sets: SYS1.LINKLIB and data sets 
concatenated to it, SYS1.DSSVM, SYS1.DUMPxx, SYS1 .STGINDEX, page 
data sets, and swap data sets. 


Note: Although it is impossible to demount the devices physically, 3344 emulated 
3340 devices and 3350 emulated 3330-1 and 3330-11 devices are not automatically 

marked permanently resident. You must instead, mark their respective VATLST J 
entries yourself. 


A reserved volume remains mounted until the operator issues an UNLOAD or a 
VARY OFFLINE command. A volume is marked reserved when it is so designated in 


a volume attribute list, or when the operator issues a MOUNT command for the 
volume. 


A removable volume can be demounted after its last use in a job, or when the 
device on which it is mounted is needed for another volume. Any volume not 
designated as either permanently resident or reserved is considered removable. The 
operator can change a removable volume to a reserved volume by issuing the 
MOUNT command for the volume. 


The use attribute controls the type of request for which a volume can be 
assigned: a specific volume request, a temporary, non-private non-specific volume 
request, or a non-temporary, non-private, non-specific »~lume request. Three use 
attributes are used for allocating these types of volume requests, as follows: 


e A private volume is allocated only to a specific volume request. For further 
information on this attribute see OS/VS2 JCL. 


e A public volume is allocated to a temporary, non-specific volume request 


(or possibly to a specific volume request). Thus, a scratch data set would 
be placed on a public volume. ) 
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VATLSTxx (continued) 


e A Storage volume is allocated primarily to a non-temporary non-specific 
volume request. (A temporary non-specific volume request may also be 
allocated to a storage volume. A storage volume can also be allocated to a 
specific volume request.) 


Note: A storage volume is required by the SAVE subcommand of EDIT for a newly 
created data set. If a STORAGE volume is not available, the SA VE subcommand 


cannot save the data set. 


For additional information on the public and storage attributes, see OS/VS2 
System Programming Library: Job Management — Allocation Services section. 


Processing the VATLSTxx Member(s) 
Volume Attribute Processing reads the VATLSTxx member(s) that were specified in 


the VAL parameter. If an invalid VATLST entry is detected, an informational 
message (IEA855]) is issued, and processing continues with the remaining entries. 
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VATLSTxx (continued) J 


If an I/O error occurs during the reading, the operator is given the option to receive 
an informational message (IEA850I) that lists all the volumes, device types, and 
attributes that will be processed. A second message (IEA8534A) allows the operator 
to choose one of several recovery options: 


Continue processing any remaining lists. 

Stop the processing of remaining lists. 

Specify a new VATLSTxx member by replying r0,xx. (The xx is the 
two-character identifier for VATLSTxx.) 

e If necessary, the operator can re-IPL the system. 


Volume Attribute Processing compiles a list of all VATLSTxx entries. If a 
particular volume serial number appears on more than one entry, the volume 
attributes specified in the last entry for that volume serial will be accepted. If the 
volume serial does not duplicate another entry, but is for an MSS volume (see the 
‘device type’ parameter description), then the last entry with that particular MSS 
unit address will be used to set the volume attributes for the volume. 


When Volume Attribute Processing has set mount and use attributes for all 
mounted volumes specified in the VATLSTxx entries, it issues a macro to mount all 
unmounted MSS volumes. When all MSS volumes have been mounted and their 
attributes set, it issues mount messages (IEA85 1I and IEA851A) for entries that 
specify unmounted volumes (unless mount message suppression was requested in the 
entries). Mount messages can be issued for unmounted volumes, up to the maximum 
number of processed entries. As many as 300 unique VATLSTxx entries can be J 
processed at one IPL. 


The operator may respond to the mount messages by replying with a valid unit 
address of the requested device type (e.g., 3330-1 or 2305-1). If the operator 
chooses to mount no volumes, he replies ‘U’, END, or ENTER. 


If the device addresses that the operator enters are invalid (e.g., invalid unit 
address, or a path to a device is not available), he can reenter new unit addresses. He 
may enter ‘U’, END, or ENTER to indicate that no more volumes will be mounted. 


When message IEA860A lists the devices that need volumes, the operator should 
mount the required volumes on the replied devices. When all devices have become 
ready (green lights on — this is different from volume just being mounted), the 
operator replies ‘U’, END or ENTER to message IEA860A. Volume Attribute 
Processing then scans for mounted volumes. 


If a volume that did not appear in the mount message is mounted on a unit 
specified by the operator, it is unloaded. The volume is also unloaded if the operator 
mounts the requested volume on a device type other than the one specified in the 
volume attribute list, or on an unrequested unit. 
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VATLSTxx (continued) 


If all the required devices do not become ready, Volume Attribute Processing 
issues message IEA893A, that lists the devices that are not ready. If the operator 
intends to ready these devices, he may do so before replying ‘U’, END, or ENTER 
to the message. If he cannot mount a volume on a device for some reason (e.g., 
hardware problem), he should reply NO to the message, after all other required 
devices have been processed. This response indicates to Volume Attribute 
Processing that no more volumes will be mounted. 


(See OS/VS Message Library: VS2 System Messages for detailed 
information on Volume Attribute messages IEA8SOI-855, IEA859-861, 
JEA866, 867, IEA893-895 , IEA947-949, and IEA985-987. 


Parameter in IEASYSxx: VAL= \ ee t 
(or entered by the operator) ited i 


Two alphameric characters (e.g., Al or 30) are appended to VATLST to specify the 
VATLSTxx member(s) of parmlib. If the parameter is not specified either in 
JEASYSxx or by the operator, the default member VATLSTO0 is used, if it exists. 
(VATLSTO0 is built by the installation, not through sysgen.) If the VAL parameter 
specifies multiple members, the members are processed in the order specified. If a 
particular volume serial number appears on more than one entry, the volume 
attributes specified in the last entry for that volume serial will be accepted. If the 
volume serial does not duplicate another entry, but is for an MSS volume (see the 
‘device type’ parameter description), then the last entry with that particular MSS 
unit address will be used to set the volume attributes for the volume. If the VAL 
parameter has invalid format, or if it specifies a member that doesn’t exist in 
parmlib, the operator is prompted to respecify the member or to reply “U’ to 

cause the member to be ignored. 


Syntax Rules 


The following rules apply to the creation of a VATLSTxx member by means of the 
IEBUPDTE utility: 


e Each record consists of 80 columns, although columns 22 through 80 are 
ignored. 

e The fields are column-dependent, as shown in “Internal Parameters” (below). 

e There are only two required fields: the volume serial number and the device 
types. All other fields have defaults. 

@ Separate the adjacent fields by comma, except before the optional information 
field. 

e@ Specify all characters in EBCDIC. 
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VATLSTxx (continued) 


Syntax Example 


Columns: 1 10 12 21 23 


30565A,0,1,2305-266, a VOLUME 
In this example, a volume whose serial number is 30565A is to be mounted on a 
2305-2 and marked permanently resident. The volume’s use attribute is to be 


public. A mount message is to be issued if the volume is unmounted. The optional 
information, “paging volume”’, is ignored but will appear in installation printouts. 


IBM-Supplied Defaults 


No default member is supplied by IBM. The installation can, however, create its 
own default member, named VATLSTOO. 


Internal Parameters 


The column dependency of fields and the associated separators are depicted in the 
following figure. Tabular description of fields follows the figure. 


Column: 7 8 91011 20 21 22 23 
Vol. serial no. Te type optional 
(up to 6 char’s.) (up to 8 char’s.) information 


Padded with blanks at 
right, if volume 











Padded with blanks, blank (optional) 


if device type 






serial doesn't have doesn’t have 8 mount message 

six characters. mount characters. suppression 
attribute indicator 
(chee) use attribute (1 char.) (1 char) 
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Parameter Column 
volume 1-6 
serial 

mount 8 
attribute 

use 10 
attribute 

device type 12-19 


*Supported device types are: 
2314 
3330 
3330-1 
3330V, specified as Vxxx 





VATLSTxx (continued) 


Meaning and Use 


Specifies the direct access volume whose 
mount and use attributes are to be set. 

The volume serial number must begin at the 
first character position in the record. 


Specifies whether the volume is to be 
permanently resident or reserved. Default 
is assigned if any character other than 1 is 
specified. 


0 
specifies permanently resident. 


specifies reserved. 


Specifies whether the volume is to be defined 
as Storage, public, or private. The default is 
assigned if any character other than 0 or 2 is 
specified. 


0 
specifies storage. 


specifies public. 
2 
specifies private. 


Specifies the device name, such as 2305-1. 

Up to eight characters may be specified, but 
the first character must start at column 12. 
Only supported device types are acceptable.* 
This parameter indicates the basic device 

but does not denote special features, such as 
track overflow. The operator must be informed 
if the device requires a special feature to 
process the data on the designated volume. 


Caution: For 3330V volumes, do not specify 
“*3330V” as you would specify another device. 
Instead, specify ““Vxxx” where xxx is the unit 
address of the 3330V device that the volume is 
to be mounted on. 


3330 Mod 11 2305-1 
3340/3344 2305-2 
3350 


Default 
Value Range Value 
1 to 6 alphameric None 
characters, left 
justified in the field, 
and padded with 
blanks at right to 
occupy six 
columns (see 
figure). 
Oorl 0 
0-2 1 
Up to 8 characters, None 


left justified within 

the field, and padded 
with blanks at the right 
to occupy eight 
columns (see figure). 
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Parameter Column 


mount 21 
message 
suppression 


optional 23—80 
information 


VATLSTxx (continued) 


Value 
Meaning and Use Range 
Specifies whether mount messages should be N, blank, or any 
issued for the volume if it is not already character. 
mounted. This parameter is ignored for MSS 
volumes. 
N 
specifies that mount messages should be 
suppressed. 
b (or any character except N) 
specifies that mount messages 
should be issued. 
Contains any desired descriptive information. Not applicable. 


The information is not used by the system. 
It appears in installation printouts. 


158 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2 Release 3.7) 


Default 
Value 


Blank (or any 
character 
except N), 
indicating that 
mount 
messages 
should be 
issued. 


None 


J 
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Part 2.1: Auxiliary Storage Management Initialization 


This chapter gives guidelines for the effective use of page and swap data sets. 
Additional information on this subject appears under PAGE, SWAP, DUPLEX, and 
PAGNUM parameters of parmlib member IEASYSxx, and in the performance topic 
“The Pageable Link Pack Area: Its Advantages and Uses’. 


Page/Swap Operations 


The paging and swapping controllers of the auxiliary storage manager (ASM) 
attempt to maximize I/O efficiency by incorporating a set of algorithms to 
distribute the I/O load as evenly as practical. In addition, every effort is made to 
keep the system operable in situations where a shortage of a specific type of page 
(swap) space exists. As a general rule, the best system performance is obtained 
when ASM is able to use the specific resource (data set) intended to be used for a 
specific operation. The following topics discuss some of the algorithms ASM uses 
to achieve these ends. 





Paging Operations and Algorithms 


To page efficiently and expediently, ASM divides the pages of the system into 
classes, namely PLPA, common, and local. Contention is reduced when these 
classes of pages are placed on different physical devices. Additionally, some 
performance improvement can be obtained when the local page data set is 

divided into multiple local data sets, even though some devices may be large 
enough to hold the entire amount of necessary page space. The PLPA and common 
page data sets are both required data sets, and there can be only one of each. 
Because the system restricts the common area pages (PLPA, MLPA, CSA) to a 
maximum of eight megabytes, the combined space requirements of these data sets 
is amaximum of eight megabytes (excluding space for error handling). Spillage 
back and forth between these two data sets is permissible, but in the interest of 
performance, only spilling from PLPA to common should be tolerated. 


Local page data sets are placed on one of two queues: the fixed head device 
queue or the movable head device queue. The general intent of the ASM 
algorithms for device selection and channel program construction is to: 


e Favor fixed head devices: ASM attempts to write exclusively to fixed 
head devices, provided (1) they are defined, not in use, and contain free slots, 
and (2) the “‘service burst”’ (defined below) can contain all pending write 
requests. 


e Scan device queues in a circular fashion: When attempting to write, ASM 
tries to use all devices of that type (fixed or movable head) equally. To 
accomplish this task, control blocks representing these devices are chained in 
a circular queue. Each time ASM writes a group of data, it selects the next 
available device containing free space in the chain. 
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e Use write-between-read logic: Once ASM selects a device, it intersperses read 
and write requests to accomplish the required I/O in the fewest possible 
revolutions of the device. 


e Use service bursting. When ASM starts an I/O request for a paging data set, it 
starts only the number of requests that can be completed in a given “‘service 
burst’ (currently set to 50 milliseconds). The number of pages read or 
written during a service burst varies as channel and device contention varies, 
thereby producing a “‘load balance’’. 


e@ Use arm position information. By remembering the previous arm position, 
ASM can often accomplish I/O with little or no arm motion on movable head 
devices. 


Note: Because ASM has no control over other users, the remembered 
position may be erroneous when devices are shared with other users. 


If a duplex page data set is specified on a CLPA IPL, ASM “duplexes” the pages 
written to the PLPA and common page data sets on the duplex data set to provide 
greater system reliability. If a read request for either the PLPA or common page 
data sets fails, ASM tries to read from the duplex page data set; if successful, system 
operation remains uninterrupted. Whenever the duplex page data set becomes full, 
ASM suspends duplexing but can read from that data set when the need arises. 


If the user supplies no swap data sets, or if the swap data sets are temporarily 
filled, ASM writes the swap LSQA pages to a local page data set. This situation is 
inadvisable because it may reduce page or swap (and therefore system) 
performance. 


Swap Operations and Algorithms 


ASM sends LSQA pages to special swap data sets as long as they are defined and 
contain free space. A swap data set consists of groups of 4096-byte slots called 
“swap sets’. Each swap set consists of twelve contiguous slots. Swap data sets use 
only one seek per swap set. To ensure this seek efficiency, ASM prevents the swap 
set from crossing cylinder boundaries and uses the direct access device multi-track 
feature. 


There are two classes of data sets for swap operations: 1) fixed-head devices and 
2) movable-head devices. ASM places a control block representing each data set on 
one of two circular queues (which represent either the fixed or movable head 
devices). ASM uses fixed-head devices for the swap operation as long as they are 
available and not full. ASM uses movable-head devices only when: 


@ no fixed head device is defined 
@ none are free 
@ none contain free space. 


ASM frees swap sets immediately upon swap-in; that is, swap pages are valid on the 
swap data set only for that period between swap-out and swap-in. 
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Page and Swap Data Set Sizes 


Page and swap data set sizes can affect system performance. Note the following 
recommendations: 


e PLPA data set. Where possible, the PLPA page data set should reside on a 
fixed-head device, or exclusively on a movable-head device because it is a 
high usage data set. If a fixed-head device is used for the PLPA data set, one 
can place other data sets on the device if enough space is available. However, 
if the common page data set has a higher use rate, it should be on the fixed 
head device in place of PLPA unless there is enough space for both data sets 
to be on a fixed head device. 


The total combined size of the PLPA page data set and common page data 
set cannot exceed eight megabytes. In defining the size of these data sets, a 
reasonable starting value might be four megabytes each, as spilling will occur if 
the PLPA data set becomes full. After the system is running, RMF reports 
can be used to determine the exact size requirements of these data sets. 


@ Common page data set. The common page data set should be large enough to 
contain all of the common area pages, plus room for any expected PLPA spill. 
Although it is possible for the common page data set to spill to the PLPA 
page data set, this situation should not be allowed to occur because it may 
heavily impact performance. As noted for the PLPA data set, a reasonable 
starting size for the common page data set might be 4 megabytes. After the 
system is running, RMF reports can be used to determine the exact size 
requirements of this data set. 


e Duplex page data set. The duplex page data set should be large enough to 
hold all the pages residing on both the PLPA and the common page data sets. 
A data set size of eight megabytes should therefore always be sufficient 
because the total combined size of the PLPA and common page data sets can 
approach eight megabytes. After the system is running, RMF can be used to 
determine the exact size requirement of this data set. 


e Local page data sets. The local page data sets must be large enough to hold 
all of the private area and VIO pages of the system. To estimate the amount 
of space required for local page space, one should understand the 
ILRSLOTC and ILRSLOTV values. 


ILRSLOTC and ILRSLOTV Values 


ASM reserves slots as backup for each address space created (defined here as a TSO 
terminal, batch address space, or VIO data set). The total slots available for user 
address spaces is equal to the total data set space defined as local. ASM 

calculates the number of slots to reserve as follows: 


1) Fora TSO terminal or batch address space, ASM computes the number of slots 
needed for mapping the user private area. ASM then divides this value by the 
constant ILRSLOTC in the nucleus CSECT ILRSLOTC (currently initialized to 
eight). 
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2) Fora VIO data set, ASM uses the maximum relative page number value 
specified as part of the ASSIGN request for the number of slots required. ASM 
then divides this value by the constant ILRSLOTV in the nucleus CSECT 
ILRSLOTV (currently initialized to four). 


As ASM creates each address space, it subtracts the anticipated number of slots for 
that address space (the reserve) from the available slot count. When there are no 
longer enough slots available, ASM rejects the creation of an address space. 


Example: Expressed in terms of cylinders per paging data set, the reserve for each 
address space might be calculated as follows: 


8 megabytes — average private area Si 
eee eee 1 megabyte of address space 
8 — default constant 
This one-megabyte reserve space is represented by 245 slots, which are 
equivalent to 4.2 cylinders on a 3330 paging device, or 8.2 cylinders on a 2314 
paging device (see Figure 2.1-1). 


Therefore, for each address space that ASM creates, the number of cylinders 
available for paging is reduced by 4.2 for a 3330 or 8.2 for a 2314. 


Changing ILRSLOTC and ILRSLOTV Values 


You can change the ILRSLOTC and ILRSLOTV values by using the AMASPZAP 
service aid so that ASM subtracts either more or fewer slots from the number of 
available slots when creating each address space. (The ILRSLOTC value is for 
batch address spaces, while ILRSLOTV is for VIO data sets.) For example, if you 
increase ILRSLOTC from eight to 16, then approximately 500,000 bytes of address 
space is subtracted from the number of available slots with the address space assign- 
ment. This is approximately 123 slots (2.2 cylinders on a 3330, or 4.1 cylinders on 
a 2314). Conversely, you can also decrease the slot values to reserve more slots. 
You can also modify the ILRSLOTC value to maintain the suggested one-megabyte 
reserve per address space when the private area size is not eight megabytes. 


Note: Error message IEA890I, a 03C wait state, or a system completion code of 
OE1 may indicate that the reserve count is exhausted. 


Example 1: You can change the value of the ILRSLOTC and ILRSLOTV constants 
by using the AMSPZAP service aid. The following control cards change the value 
from eight to the value of x, or the value of four to the value of y (where x and y 
are installation-defined value): 


NAME JEANUCO1 ILRSLOTC 


VER 00 00000008 
REP 00 O000000x 
NAME JEANUCO1 ILRSLOTV 
VER 00 00000004 
REP 00 O000000y 
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Example 2: You can also use the HMASMP service aid to perform the same 
operation by preparing the following control cards: 


++PTF(number) 

++ZAP(ILRSLOTC) DISTLIB(AOSCS) 
NAME ILRSLOTC 
VER 00 0000,0004 
REP 00 0000,000x 
NAME ILRSLOTV 
VER 00 0000,0004 
REP 00 0000,000y 


e@ Swap data set. When defining a swap data set, one should allow enough space 
so that spillage to the local data set never occurs. Generally, one swap set 
(group of slots) per address space plus a buffer of 20-50% is sufficient. If, 
however, the LSQA for specific address spaces exceeds the swap set size 
(currently 12 pages), this value may need increasing. The number of swap 
sets per cylinder varies on different devices. Figure 2.1-2 provides device- 
related data for calculating the number of necessary cylinders. RMF reports 
can ultimately be used to verify correct values. 


Space Calculation Examples 
Figures 2.1-1 and 2.1-2 show the values respectively for page and swap data sets. 


The examples following these figures show how to apply their tabular information 
to typical initialization considerations. 


soni 


fixed head 1,200 
2,496 


movable head 


pe 
46,864 
8,352 
16,704 
65,520 (max usable) 





Figure 2.1-1. Page Data Set Values 
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Device Category Slots/Cyl |Swap Sets/Cyl | Swap Sets/Device 


movable head 






: used 
57 
24 
24 










Note: ASM uses space on a swap data set tweive slots at a time; all twelve slots 
must be in one cylinder. Therefore, the 3330 devices with 57 slots per 
cylinder available only use 48 (4 x 12) slots per cylinder for swap data 
sets. 






Figure 2.1-2. Swap Data Set Values 


Example 1: Sizing the PLPA Page Data Set, Size of the PLPA Unknown 


Define the PLPA page data set to hold four megabytes; if that amount 
of space is exceeded, the remainder can be placed on the common page 
data set until the PLPA value is determined exactly. 


Therefore: From the tables, 40 cylinders on a 2305 are defined for the 
PLPA page data set. 


Example 2: Sizing the PLPA Page Data Set, Size of the PLPA Known 


Define the PLPA page data set to hold 3.5 megabytes plus 5%, or 3.67 
megabytes. (The extra 5% allows for loss of space as a result of 
permanent I/O errors.) 


Therefore: From the tables, 37 cylinders on a 2305 is defined for the 
PLPA page data set. 


Example 3: Sizing the Common Page Data Set 


Assume that the exact size of the PLPA is unknown, but the 

PLPA page data set is defined to hold four megabytes. The combined 
sizes of PLPA and common page data sets need not exceed eight 
megabytes. For practical purposes, it is appropriate to use a total value 
of eight megabytes and consider the excess as a “buffer” value in case 
of errors. The total size (eight megabytes) minus the PLPA size (four 
megabytes) results in a definition of a four megabyte common page 
data set. 


Therefore: From the tables, 88 cylinders on a 3340 is defined for 
the duplex page data set. 
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Example 4: 


Example 5: 


Sizing the Duplex Page Data Set 


Assume that the combined sizes of the PLPA and common page data 
sets cannot exceed the value of eight megabytes minus the size of the 
nucleus and SQA. Use the total size of eight megabytes and consider 
the extra space as a buffer in case of permanent I/O errors. 


Therefore: From the tables, 88 cylinders on a 3340 is defined for the 
duplex page data set. 


Sizing Local Page Data Sets 


Assume that the master address space and JES address space can each 
use about eight megabytes of private area storage. Next, determine the 
number of address spaces that will be used for subsystem programs 
such as VTAM, and allow eight megabytes of private area storage for 
each. To determine the amount of space necessary for batch address 
spaces, multiply the maximum number of batch address spaces that 
will be allowed to be active at once by the maximum size of that 
private area (IEALIMIT value if the exit is supplied by the user — see 
IEALIMIT in OS/VS2 System Programming Library: Supervisor — 

or estimated size of REGION parameter). 


To determine the amount of space necessary for TSO, multiply the 
maximum number of TSO address spaces allowed on the system at 
once by the maximum size of that private area (IEALIMIT value if the 
exit is supplied by the user, or the estimated size of the REGION 
parameter). 


Finally, estimate the space requirements for VIO data sets. 
Approximate this requirement by multiplying the expected number of 
VIO data sets used by the entire system by the average size of a VIO 
data set for the installation. After the system is fully loaded, you can 
use MF/1 or RMF reports to evaluate the estimates. 


For example purposes, assume that the total space necessary for 
local data sets is: 


8 megabytes for the master address space 
8 megabytes for the VTAM address space 
8 megabytes for the JES address space 
6 megabytes for the batch address spaces (6 batches x 1 meg! each) 
40 megabytes for TSO address spaces (40 TSO users x 1 meg’ each) 
+ 20 megabytes for VIO data sets (100 data sets x 0.2 meg each) 


90 megabytes total + 4 meg (approx. 5%) buffer = 94 megabytes 


Therefore. From the tables, 423 cylinders on 3330 type devices are 
necessary. 


"These values are one megabyte because the eight megabyte private 
area is divided by the ILRSLOTC default value (which is eight). 


Part 2.1: Auxiliary Storage Management Initialization 158.7 


VS2.03.807 


Example 6: Sizing Swap Data Sets 


Assume that six batch address spaces and 50 TSO address spaces 
constitute the maximum number of address spaces to be active at any 
given time. At least one swap set is necessary for each, and some may 
require two. Additionally, define a few extra swap sets in case of disk 
pack errors. A good starting value is therefore 1.5 swap sets times the 
maximum number of address spaces, or in this example: 


56 x 1.5 = 84 swap sets 


Therefore: From the table, 42 cylinders on a 2305 is defined for the 
swap data set. 


Performance Recommendations 


The following recommendations may improve system performance through the 
careful use of paging data sets and devices: 


e If you place multiple paging data sets on movable-head devices (3330s, for 
example) try to avoid placing more than one paging data set on any single 
movable-head device. Doing this reduces contention among multiple data 
sets for the use of the device. 


Reason: When ASM starts I/O requests for a paging data set, it starts only the 
number of requests that can complete within a service burst (currently set to 
50 milliseconds). If multiple paging data sets are on the same device, con- 
tention for use of the device is more likely compared with one paging data 
set per device, and ASM therefore adjusts the length of time (the service 
burst) allowed for request completion. Consequently, the request takes 
longer than expected, and fewer requests can start the next time. 


Comments: You can experiment with multiple page data sets per device and 
check for dévice contention by executing MF/1 or RMF with typical job 
streams to obtain Direct Access Device Activity reports during various time 
intervals. The MF/1 or RMF data on device activity count, percent busy, and 
average queue length should suggest whether device contention is a problem. 
MF/1 or RMF data for devices that contain only one data set can be used as a 
comparison base. 


You may, however, place low-activity non-paging data sets on a device 
that holds a paging data set. You can then use the MF/! or RMF Direct 
Access Device Activity report to detect whether device contention is 
occurring. 


@ Specify a data set to contain the primary copy of PLPA exclusively. You can 
do this by specifying the data set as the first dsname in the PAGE parameter 
in IEASYSxx or as the first dsname in the first DATASET macro containing 
the PAGEDSN parameter during sysgen. (The sysgen process places the 
dsname in PAGEDSN into IEASYSO0.) You should put the PLPA modules 
on the fastest available device because they are subject to high frequency 
usage. If real storage management steals a PLPA module page that ASM 
needs later, ASM will subsequently have to read the page from the PLPA page 
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Example 2: You can also use the HMASMP service aid to perform the same 
operation by preparing the following control cards: 


++PTF(number) 

++ZAP(ILRSLOTC) DISTLIB(AOSCS) 
NAME ILRSLOTC 
VER 00 0000,0004 
REP 00 0000,000x 
NAME ILRSLOTV 
VER 00 0000,0004 
REP 00 0000,000y 


e@ Swap data set. When defining a swap data set, one should allow enough space 
so that spillage to the local data set never occurs. Generally, one swap set 
(group of slots) per address space plus a buffer of 20-50% is sufficient. If, 
however, the LSQA for specific address spaces exceeds the swap set size 
(currently 12 pages), this value may need increasing. The number of swap 
sets per cylinder varies on different devices. Figure 2.1-2 provides device- 
related data for calculating the number of necessary cylinders. RMF reports 
can ultimately be used to verify correct values. 


Space Calculation Examples 


Figures 2.1-1 and 2.1-2 show the values respectively for page and swap data sets. 
The examples following these figures show how to apply their tabular information 
to typical initialization considerations. 


Slots/Cyl | Cyl/Meg Slots/Device 


fixed head 1,200 
2,496 


movable head 6,000 


23,432 
46,864 
8,352 
16,704 
65,520 (max usable) 





Figure 2.1-1. Page Data Set Values 
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Slots/Cyl |Swap Sets/Cyl | Swap Sets/Device 


fixed head 2305-1 
2305-2 


movable head 










Fe used 
57 
24 
24 










Note: ASM uses space on a swap data set twelve slots at a time; all twelve slots 
must be in one cylinder. Therefore, the 3330 devices with 57 slots per 
cylinder available only use 48 (4 x 12) slots per cylinder for swap data 
sets. 






Figure 2.1-2. Swap Data Set Values 


Example 1: Sizing the PLPA Page Data Set, Size of the PLPA Unknown 


Define the PLPA page data set to hold four megabytes; if that amount 
of space is exceeded, the remainder can be placed on the common page 
data set until the PLPA value is determined exactly. 


Therefore: From the tables, 40 cylinders on a 2305 are defined for the 
PLPA page data set. 


Example 2: Sizing the PLPA Page Data Set, Size of the PLPA Known 


Define the PLPA page data set to hold 3.5 megabytes plus 5%, or 3.67 
megabytes. (The extra 5% allows for loss of space as a result of 
permanent I/O errors.) 


Therefore: From the tables, 37 cylinders on a 2305 is defined for the 
PLPA page data set. 


Example 3: Sizing the Common Page Data Set 


Assume that the exact size of the PLPA is unknown, but the 

PLPA page data set is defined to hold four megabytes. The combined 
sizes of PLPA and common page data sets need not exceed eight 
megabytes. For practical purposes, it is appropriate to use a total value 
of eight megabytes and consider the excess as a “‘buffer” value in case 
of errors. The total size (eight megabytes) minus the PLPA size (four 
megabytes) results in a definition of a four megabyte common page 
data set. 


Therefore: From the tables, 88 cylinders on a 3340 is defined for 
the duplex page data set. 
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Example 4: 


Example 5: 


Sizing the Duplex Page Data Set 


Assume that the combined sizes of the PLPA and common page data 
sets cannot exceed the value of eight megabytes minus the size of the 
nucleus and SQA. Use the total size of eight megabytes and consider 
the extra space as a buffer in case of permanent I/O errors. 


Therefore: From the tables, 88 cylinders on a 3340 is defined for the 
duplex page data set. 


Sizing Local Page Data Sets 


Assume that the master address space and JES address space can each 
use about eight megabytes of private area storage. Next, determine the 
number of address spaces that will be used for subsystem programs 
such as VTAM, and allow eight megabytes of private area storage for 
each. To determine the amount of space necessary for batch address 
spaces, multiply the maximum number of batch address spaces that 
will be allowed to be active at once by the maximum size of that 
private area (IEALIMIT value if the exit is supplied by the user — see 
IEALIMIT in OS/VS2 System Programming Library: Supervisor — 

or estimated size of REGION parameter). 


To determine the amount of space necessary for TSO, multiply the 
maximum number of TSO address spaces allowed on the system at 
once by the maximum size of that private area (IEALIMIT value if the 
exit is supplied by the user, or the estimated size of the REGION 
parameter). 


Finally, estimate the space requirements for VIO data sets. 
Approximate this requirement by multiplying the expected number of 
VIO data sets used by the entire system by the average size of a VIO 
data set for the installation. After the system is fully loaded, you can 
use MF/1 or RMF reports to evaluate the estimates. 


For example purposes, assume that the total space necessary for 
local data sets is: 


8 megabytes for the master address space 
8 megabytes for the VTAM address space 
8 megabytes for the JES address space 
6 megabytes for the batch address spaces (6 batches x 1 meg! each) 
40 megabytes for TSO address spaces (40 TSO users x 1 meg! each) 
+ 20 megabytes for VIO data sets (100 data sets x 0.2 meg each) 


90 megabytes total + 4 meg (approx. 5%) buffer = 94 megabytes 


Therefore: From the tables, 423 cylinders on 3330 type devices are 
necessary. 


These values are one megabyte because the eight megabyte private 
area is divided by the ILRSLOTC default value (which is eight). 
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Example 6: Sizing Swap Data Sets 


Assume that six batch address spaces and 50 TSO address spaces 
constitute the maximum number of address spaces to be active at any 
given time. At least one swap set is necessary for each, and some may 
require two. Additionally, define a few extra swap sets in case of disk 
pack errors. A good starting value is therefore 1.5 swap sets times the 
maximum number of address spaces, or in this example: 


56 x 1.5 = 84 swap sets 


Therefore: From the table, 42 cylinders on a 2305 is defined for the 
swap data set. 


Performance Recommendations 


The following recommendations may improve system performance through the 
careful use of paging data sets and devices: 


e Ifyou place multiple paging data sets on movable-head devices (3330s, for 
example) try to avoid placing more than one paging data set on any single 
movable-head device. Doing this reduces contention among multiple data 
sets for the use of the device. 


Reason: When ASM starts I/O requests for a paging data set, it starts only the 

number of requests that can complete within a service burst (currently set to 

50 milliseconds). If multiple paging data sets are on the same device, con- ve 
tention for use of the device is more likely compared with one paging data 

set per device, and ASM therefore adjusts the length of time (the service 

burst) allowed for request completion. Consequently, the request takes 

longer than expected, and fewer requests can start the next time. 


Comments: You can experiment with multiple page data sets per device and 
check for dévice contention by executing MF/1 or RMF with typical job 
streams to obtain Direct Access Device Activity reports during various time 
intervals, The MF/1 or RMF data on device activity count, percent busy, and 
average queue length should suggest whether device contention is a problem. 
MF/1 or RMF data for devices that contain only one data set can be used as a 
comparison base. 


You may, however, place low-activity non-paging data sets on a device 
that holds a paging data set. You can then use the MF/1 or RMF Direct 
Access Device Activity report to detect whether device contention is 
occurring. 


e Specify a data set to contain the primary copy of PLPA exclusively. You can 
do this by specifying the data set as the first dsname in the PAGE parameter 
in IEASYSxx or as the first dsname in the first DATASET macro containing 
the PAGEDSN parameter during sysgen. (The sysgen process places the 
dsname in PAGEDSN into IEASYS00.) You should put the PLPA modules 
on the fastest available device because they are subject to high frequency 
usage. If real storage management steals a PLPA module page that ASM 
needs later, ASM will subsequently have to read the page from the PLPA page 
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data set. This read operation is faster if the PLPA page data set is on a fast 
device, for example a fixed-head device. Avoid placing other paging data sets 
on the same device unless you are using a fixed-head device (such as a 
2305-2). For additional suggestions about the PLPA, see the topic “The 
Pageable Link Pack Area: Its Advantages and Use’. 


Note: The common page data set or local page data sets may be placed on the 
fastest device if either or both show a higher use rate than the PLPA page data 
set’s use rate. 


Reason: The PLPA is a high usage data set. It is desirable to speed the access 
to this data set and to avoid device contention. It may be possible to share 
the device with other performance-sensitive data sets, such as the primary 
spool volume (checkpoint records and spool messages queue only), provided 
contention does not develop. You may use the MF/1 or RMF Direct Access 
Activity report to check for possible device contention. 


e Place most paging data sets on moderate speed devices, such as 33xx’s, to 
avoid overloading the faster devices. You should probably place only one 
paging data set (the PLPA) plus the primary spooling data set on the faster 
device (such as a 2305-2), An exception to this general rule involves the swap 
data set or paging data sets for a large time sharing or teleprocessing installa- 
tion for which response time is critical. Such uses may require the fastest 
device obtainable. 


Reason: The fastest devices should be used for the most critical applications. 
In general, this does not include local page data sets. However, to take 
advantage of the 33xx type of devices (reasonable speed plus size), ASM splits 
the paging load as evenly as possible across all defined local page data sets. To 
do this, ASM divides the local page data sets into two classes — fixed-head 
devices and movable-head devices. The control blocks for each of these classes 
are then arranged in a circular queue. ASM uses defined fixed-head devices as 
long as they contain free slots and are not in use. ASM scans the circular 
queue while work is pending. This causes all the data sets on the queue to be 
used in equal proportions. ASM also uses the movable-head devices in exactly 
the same way, but only if no fixed-head device can be selected. 


Note: Using 2314s as paging devices is inadvisable because circular queueing 
causes them to be used as often as every other data set in the queue. 


e@ Overspecify space for all page data sets to allow for the creation of additional 
address spaces before the deletion of current ones, and to permit some 
reasonable increase in the number of concurrent VIO data sets. VIO data-set 
growth may become a problem because there is no simple way to limit the 
total number of VIO data sets used by multiple jobs and TSO sessions. One 
method for eliminating VIO data sets is to re-IPL, specifying CVIO, but this 
action prevents warm start for the jobs that are using VIO data sets. (For 
additional space considerations, see the guideline for estimating paging space 
later in this topic.) 
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e Use multiple local page data sets even if the total required space is 
containable on one device. 


Reason: When ASM uses multiple data sets, it can page concurrently on 
multiple devices. This is especially important during peak loads. 


e Distribute ASM data sets among channels and control units. 


Reason: Although ASM attempts to use multiple data sets concurrently, the 
request remains in the I/O supervisor queues if the channel or control unit is 
busy. 


Estimating Total Size of Paging Data Sets 


You may obtain a general estimate of the total size of all paging data sets by 
considering the following space factors (a general formula for this calculation is in 
OS/VS2 System Programming Library: Storage Estimates). 


1. The space needed for the common areas of virtual storage (PLPA, MLPA, and 
CSA). Double this space estimate if duplexing is desired. 


2. The space needed for areas of virtual storage that are not duplexed: private 
areas of concurrent address spaces, and concurrently existing VIO data sets. 
(The system portion of concurrent address spaces needs to be calculated only 
once, since it represents the same system modules.) 


Using Measurement Facilities 


You can possible simplify the space estimation for the private areas mentioned 
above by picking an arbitrary value. Set up this amount of paging space, and then 
run the system with some typical job loads. To determine the accuracy of your 
estimate, start MF/1 or RMF while the jobs are executing. The Paging Activity 
Report of either measurement program gives data on the number of unused 4K 
slots, the number of VIO data set pages and address space pages, and the number of 
unavailable (defective) slots. (See the topic “Using the Paging Activity Report” in 
“Part 4: How to Use the System Activity Measurement Facility (MF/1)” for 
additional information.) The Auxiliary Storage User Pool portion of the MF/1 
Paging Activity Report indicates a snapshot of slot usage at the end of the report 
interval. 


The RMF version of the report replaces the snapshot values with average values 
based on a number of samples taken during the report interval. These average 
values are in a portion of the report entitled ““Local Page Data Set Slot Counts”. 
They are somewhat more representative of actual slot usage because slot usage is 
likely to vary during the report interval. The values from the Paging Activity 
Report of either measurement program should enable you to adjust your original 
space estimate as necessary. 
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Adding More Paging Space 


To add more paging space, you 1) must use the DEFINE PAGESPACE command 
of access method services to preformat and catalog each new page data set, and 
2) may use the PAGEADD operator command or specify the data set at the next 
IPL by means of the PAGE parameter. (See OS/VS2 Access Method Services for 
information about the DEFINE PAGESPACE command, and on the related 
commands — ALTER and DELETE — used for the handling of VSAM data sets. 
Also see the description of the PAGE parameter in parmlib member IEASYSxx in 
“Part 2: System Initialization” in this manual. 


Questions and Answers 


Customers have often asked the following questions about ASM: 


Q: 
A: 


What happens if there is an unrecoverable I/O error on a paging device ? 


If the error occurs during the reading of a common duplexed area and 
duplexing is active, the secondary copy is read. If an I/O error occurs during 
the reading of a non-duplexed area or if duplexing is not active, the job 
terminates, and all non-sharable devices are freed. If an error is detected on 
output, the pageout is retried to a different slot. However, since there is no 
readback check, ASM may not know if a data error occurred. 


- Does ASM use I/O load balancing ? 


Yes, it does its own, by keeping a history of the average length of time to read 
or write one page on each paging data set, then starting more or fewer page 
requests depending on how fast page requests are being satisfied by the device. 
By starting only 50 milliseconds’ worth of requests to each page space, ASM 
keeps CCW strings relatively short, and therefore spreads resources among all 
paging data sets. ASM can react quickly to busy spurts on particular devices 
or channels and favor those devices or channels that are providing the best 
service. 


How does the auxiliary storage shortage prevention algorithm in the SRM 
prevent shortages ? 


It does so by swapping out address spaces that are accumulating paging space 
at arapid rate. Page space is not immediately freed, but another job or TSO 
session (still executing) will eventually complete and free page space. The 
SRM also prevents the creation of new address spaces and informs the operator 
of the shortage so that he can optionally cancel a job. 


: Is running out of auxiliary storage (paging space) catastrophic ? 


- No, not necessarily; it may be possible to add more page data sets via the 


PAGEADD operator command. Additionally, after determining what kind of 
workload placed a heavy demand on paging space (TSO, batch storage, or 
VIO), it may be possible to modify key ASM constants (ILRSLOTC and 
ILRSLOTV) prior to re-IPLing with the same page data sets. Otherwise, it is 
necessary to re-IPL to specify an additional preformatted and cataloged page 
data set. (See the description of the PAGE parameter of the IEASYSxx 
member in the “System Initialization” chapter.) 
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Q: Can we dynamically allocate more paging space ? 


A: Yes. Additional paging space may be added via the PAGEADD operator 
command if the PAGNUM parameter allowed for expansion (See the descrip- 
tion of the PAGNUM parameter of the IEASYSxx member in the “System 
Initialization” chapter, and PAGEADD operator command in Operators 
Library: OS/VS2 MVS JES2 Commands). 


Q: Should 2314s be used as ASM data sets ? 


A: Generally speaking, the answer is no because 2314s tend to be too slow for 
most paging applications. The duplex page data set represents the possible 
exception to this general rule because this data set experiences few (if any) 
read operations. The activity to this data set after IPL is limited mostly to 
common area write operations (excluding PLPA). 


Q: How does ASM select slots ? 


A: ASM first selects a cylinder on a page space, maintaining a circular action of 
the disk arm from the beginning of the data set to the end, then starting over 
at the beginning again. ASM remembers the last arm position and selects the 
nearest cylinder beyond the one last processed. When it selects a cylinder, it 
chooses slots with the cylinder according to the best rotational position of 
eligible slots. ASM follows the same procedure for a 2305 device (reads from 
low-numbered slots are not favored over reads from high-numbered slots). 


Q: How does ASM Select a local page data set for a page-out ? 


A; ASM selects a local page data set for page-out from either fixed-head or 
movable-head lists of available paging data sets. As long as fixed-head devices 
are available, are not in use, and contain free space, ASM uses these devices. 
If no fixed-head device is available, ASM uses the movable-head devices. 
ASM then selects the first available page data set and starts a 50-millisecond 
burst of work. ASM continues around the list until either there is no more 
work to do or no more page data sets are available. 
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Part 3: The System Resources Manager 


Introduction 


Section 1: 


To a large degree, an installation’s control over the functioning of the OS/VS2 
system is exercised through the system resources manager (SRM). The following 
sections describe the types of control available through the SRM, the functions 
used to implement these controls, the concepts inherent in the use of SRM 
parameters, and the parameters themselves. 


Guidelines are presented for defining these parameters and several complete 
sample specifications are described. Finally, a list of potential problems along with 
guidelines for evaluation and adjustment of parameters are provided. 


System Tuning and the SRM 


The task of tuning a system is an iterative and continuous process. The controls 
offered by the SRM are only one aspect of this process. Initial tuning consists of 
selecting appropriate sysgen parameters and parameters for various components and 
subsystems of MVS, such as TCAM and JES2. Once the system is operational and 
criteria have been established for the selection of jobs for execution via job classes 
and priorities, the SRM will control the distribution of available resources according 
to the parameters specified by the installation. 





The SRM, however, can only deal with available resources. If these are 
inadequate to meet the needs of the installation, even optimal distribution may not 
be the answer — other areas of the system should be examined to determine the 
possibility of increasing available resources. 


When requirements for the system increase and it becomes necessary to shift 
priorities or acquire additional resources, such as a larger processor, more storage, 
more terminals, etc., the SRM parameters may have to be adjusted to reflect 
changed conditions. 


Description of the System Resources Manager (SRM) 


The SRM is a component of the MVS control program. It determines which 
address spaces, of all active address spaces, should be given access to system 
resources and the rate at which each address space is allowed to consume these 
resources. 


Before an installation turns to the SRM, it should be aware of the response time 
and throughput requirements for the various types of work that will be performed 


on its system. Questions similar to the following should be considered: 


e How important is turnaround time for batch work, and are there distinct types 
of batch work with differing turnaround requirements ? 
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e Should subsystems such as IMS and CICS be controlled at all, or should they 
receive as much service as they need ? That is, should they be allowed unlimited 
access to resources without regard to the impact this would have on other types 
of work ? 


e What is acceptable TSO response time for various types of commands ? 


e@ What is acceptable response time for compiles, sorts, or other batch-like work 
executed from a terminal ? 


(Guidelines for defining installation requirements are discussed in Section 3). 


Once these questions have been answered and, whenever possible, quantified, 
and the installation is reasonably confident that its requirements do not exceed 
the physical capacity of its hardware, it should then turn to the SRM to specify 
the desired degree of control. 


Objectives 
The SRM bases its decisions on two fundamental objectives: 


1. To distribute system resources among individual address spaces in accordance 
with the installation’s response, turnaround, and work priority requirements. 


2. To achieve optimal use of system resources as seen from the viewpoint of 
system throughput. 


An installation specifies its requirements for the first objective in a member of 
PARMLIB called the Installation Performance Specification (IPS). Through the 
IPS, the installation divides its types of work into distinct groups, called domains, 
assigns relative importance to each domain, and specifies the desired performance 
characteristics for each address space within these domains. The meaning and use 
of domains is discussed in detail in succeeding sections. 


A secondary input to the SRM is another member of PARMLIB, the OPT 
member. Through a combination of IPS and OPT parameters, an installation can 
exercise a degree of control over system throughput characteristics (objective 
number 2). That is, the installation can specify whether, and under what 
circumstances, throughput considerations are more important than response and 
turnaround requirements when the need arises to make trade-offs between objective 
number | and objective number 2. 


The SRM attempts to ensure optimal use of system resources by periodically 
monitoring and balancing resource utilization. If resources are underutilized, the 
SRM will attempt to increase the system load. If resources are overutilized, the 
SRM will attempt to alleviate this by reducing the system load or by shifting 
commitments to underutilized resources. Examples of such resources are the CPU, 
logical channels, auxiliary storage and pageable real storage. 
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Types of Control 
The SRM offers four distinct types of control to an installation: 


@ Domain Control 

e Workload Control 

e Dispatching Priority Control 
@ Throughput Control. 


The first three derive their input from the parameters in the IPS; the fourth 
derives its input from both IPS and OPT parameters. 


The remainder of this section describes these types of control and the functions 
used by the SRM to implement them. 


Domain Control 


Domains are a mechanism that allows an installation to divide its types of work into 
distinct groups and thereby exercise individually tailored control over different 
types of work, such as batch work, IMS message processors, short TSO commands 
and long-running TSO commands. 


Domains, therefore, are simply the means by which related types of work are 

grouped together, such that all work (address spaces) assigned to one domain has 

“Some common set of characteristics that differentiates it from the work assigned to 
other domains. What constitutes such a set of characteristics is entirely dependent 
on an installation’s requirements. Work could be differentiated on the basis of 
execution characteristics such as short versus long-running and batch versus fore- 
ground, or according to different use characteristics such as IMS message processors 
and student or test programs. On the other hand, an installation may choose to use 
different user requirements as the basis for differentiating and divide its user 
population into domains, regardless of the execution characteristics of individual 
jobs. A mixture of the above considerations is, of course, equally possible. 


Domain control enables an installation to do the following: 


e@ Guarantee access to system resources to at least a minimum number of address 
spaces for each type of work. 


e Limit the number of address spaces, for each type of work, that are given access 
to system resources, 


e Assign degrees of importance to different types of work. 
An installation may use these capabilities for various purposes, such as: 


e@ To exercise either complete control, partial control, or no control at all over a 
particular type of work (or group of users). 


e@ To prevent one type of work from competing with another type of work for 
access to system resources. 


e To prevent one type of work from dominating the system. 
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The creation of domains, competition between domains, and the association of 
address spaces with domains are discussed in Section 2. 


Workload Control 


Address spaces compete for access to system resources with all other address spaces 
associated with the same domain. The installation establishes the rules for this 
competition via IPS parameters that allow specification of desired performance 
characteristics for each address space. These specifications are used by the workload 
management functions of the SRM in apportioning system resources to individual 
address spaces. 


An exampleof the competition within a domain would be a batch domain with 


different performance/through put requirements for various initiator classes, such as 
ayroll jobs versu programs. 


p s test 


Dispatching Priority Control 


The SRM maintains control over a range of 16 dispatching priorities called the 
Automatic Priority Group (APG). By placing jobs in the APG range, further 
control over their performance characteristics is gained since this enables the 
installation, via the IPS, to alter the dispatching priorities of address spaces as their 
execution characteristics change. 


Dispatching priorities control the rate at which address spaces are allowed to 
consume resources after they have been given access to these resources. This form of 
competition takes place outside the sphere of domain control, that is, all address 
spaces compete with all other address spaces with regard to dispatching priorities. 


Throughput Control 


The SRM attempts to maximize system throughput. If contention for a system 
resource is very high, bottlenecks may result, impeding throughput. For instance, 
when contention for the CPU becomes excessive, the SRM will seek out an address 
space that is a major contributor to the problem and recommend that it be denied 
access to AUR a errenepne ae a 
specify the importarité of such a load-adjusting recommendation. (The installation 

as the option of specifying, via the IPS, whether throughput considerations should 
play a role or not.) 


Another example of throughput control is the SRM’s enqueue processing. A 
user may request a serial resource that is held by another user. In this case, the 
SRM will ensure that the holder of the resource is in real storage and remains there 
for a fixed execution time interval in the hope that the serial resource is released 
before the user is swapped out. The installation has the ability to specify this time 
interval through an OPT parameter. 
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Functions 


This section discusses the functions used by the SRM to implement the controls 
described in the previous section. Constants referred to in this discussion are 
described in the section entitled “SRM Constants”. 


There are seven such functions: 


. Swapping 

. Dispatching Priority Control 

. Resource Use Functions 

. Enqueue Delay Minimization 

. Device Allocation 

. Prevention of Storage Shortages 
. Pageable Frame Stealing. 


“ANN AH WN Ee 


Swapping 


Swapping is the primary function used by the SRM to exercise control over 
distribution of resources and system throughput. Using information specified by 
the installation via IPS and OPT parameters, and system status information that is 
periodically monitored, the SRM determines which address spaces should have 
access to system resources. 


There are six distinct types of swapping. The first three described below are 
used for control of domains and the competition for resources between individual 
address spaces within a domain, while the remaining three provide control over 
system-wide performance aspects and help increase throughput. 


Unilateral swap in. If the number of a domain’s address spaces that are in real 
storage is less than the number the installation specified, or less than the SRM 
considers optimal for the domain, the SRM will swap in additional address spaces 
from that domain, if possible. 


Unilateral swap out. If the number of a domain’s address spaces that are in real 
storage is greater than the number the installation specified, or greater than the 
number the SRM considers optimal for the domain, the SRM will swap out address 
spaces from that domain. 


Exchange swap. All address spaces of a domain compete with one another for 
system resources according to the installation’s specifications in the IPS and OPT. 
When an address space in real storage has exceeded its allotted portion of resources, 
relative to an address space of the same domain waiting to be swapped in, the SRM 
performs an exchange swap. That is, the address space in real storage is swapped 
out and the other address space is swapped in. This competition between address 
spaces is described in detail in Section 2. 
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storage shortages and pageable frame shortages. If the number of available auxiliary 
storage slots is low, the SRM will swap out the address space that is acquiring 
auxiliary storage at the fastest rate. Likewise, if the number of fixed frames is very 
high, the SRM will swap out the address space that acquired the greatest number of 
fixed frames. This process continues until the number of available slots rises above 
a fixed target, or until the number of fixed frames falls below a fixed target. 


Swaps due to storage shortages. Two types of shortages cause swaps: auxiliary ) 


Swaps due to wait states. In certain cases, such as a batch job going into a long 
wait state (LONG option specified on the WAIT SVC, or a STIMER specification 
of > =0.5 seconds), the address space will itself signal the SRM to be swapped out 
in order to release storage for the use of other address spaces. Another example 
would be a time sharing user’s address space that is waiting for input from the 
terminal after a transaction has completed processing. The SRM also detects 
address spaces in a wait state. That is, address spaces in real storage that are not 
executable for a fixed interval will be swapped out. 


Request Swap. The system may request that an address space be swapped out. 
For instance, jobs which request real storage via the ADDRSPC=REAL specifica- 
tion on their job card, or nonswappable programs, will be swapped out and then 
swapped back in into a preferred area of real storage. 


Dispatching Priority Control 


In MVS, dispatching of work is done on an address space priority basis. That is, 

those ready address spaces with the highest priority are dispatched first. When an 

address space is added to the dispatching queue, it is positioned according to its J 
priority; if other address spaces with the same priority are already on the queue, it 

is added to the bottom of the group with that priority. 


The total range of priorities is from 0 to 255. The range can be divided into 16 
sets of 16 priorities each. The SRM maintains control over one such set, called the 
Automatic Priority Group (APG). The default APG range, as specified in 
PARMLIB member IEASYSO0, is 70 to 7F (HEX). The installation may choose a 
different set of 16 values, such as AO-AF (it must start with x0,) as illustrated 
below. 


Se a a a 


0 70 7F AO AF FF 
LUN a 
Lowest Default Alternate Highest 
Priority APG APG Priority 


Within the APG, specific numbers denote distinct types of priority schemes used 
by the SRM, enabling the installation to exercise precise control over the rules 
governing the dispatching of work. These rules also apply to nonswappable address 
spaces. 


(Note: the default APG range is assumed in the remaining discussions and 
examples of “Part 3: The System Resources Manager.’’) 
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Mean-time-to-wait group (70-76). 


These dispatching priorities can be used to increase system throughput by 
increasing CPU and I/O overlap. The SRM periodically monitors each address 
space’s CPU utilization. Those address spaces that are considered to be CPU-bound 
are assigned lower dispatching priorities, within this group, than those which are 
considered to be I/O-bound. This permits the CPU-bound jobs to productively use 
the time spent waiting for I/O processing to complete. 


Rotate Priority (7B). 


This priority can be used to ensure that one address space does not dominate the 
CPU in relation to all other address spaces having the same dispatching priority. 
The SRM periodically repositions the address space that is highest on the dis- 
patching queue at priority 7B to the bottom of the group of address spaces having 
that priority (7B). This means, for instance, that if two IMS control regions were 
active at the same time, using the Rotate priority would allow them to be 
dispatched on an alternate basis. 


Fixed Priorities (77-7A, 7C-7F). 


These priorities have no special significance other than that they belong to the APG 
and therefore are under the control of the SRM. 


The implications and uses of SRM control over the APG will be discussed in 
later sections. 


Resource Use Functions 


The resource use functions of the SRM attempt to optimize the use of system 
resources on a system-wide basis, rather than on an individual address space basis. 
There are three such functions: 


@ Multiprogramming Level Adjusting 
e CPU Load Adjusting 
e I/O Load Adjusting. 


The installation can influence or eliminate the effect of the multiprogramming 
level adjusting function via the parameter values of the domain specification in the 
IPS. The installation can influence or eliminate the effect of the CPU and I/O load 
adjusting functions with the response/throughput bias (RTB) and the resource 
factor coefficients (RFC) specifications in the IPS and OPT, respectively. 


Multiprogramming Level Adjusting: The SRM monitors system-wide utilization of 
resources, such as the CPU and paging subsystem, and seeks to optimize it by 
alleviating imbalances, that is, overutilization or underutilization. This is accomplished 
by periodically adjusting the number of address spaces that are allowed in real 

storage (multiprogramming level) for appropriate domains. 


For instance, when the paging rate is too high, it indicates that the percentage of 
CPU time used for productive (problem program) work is lower than it should be. 
That is, the system is being overutilized. To reduce this excessive contention for 
storage, the SRM will select a domain and reduce the number of address spaces 
allowed in real storage for that domain. 
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When system contention factors indicate that the power of the system is not 
being fully utilized, the SRM will select a domain and increase the number of 
address spaces allowed in real storage for that domain, thereby increasing 
utilization of the system. 





J 


CPU Load Adjusting: This function attempts to maintain a dispatchable job mix 
that neither underutilizes nor overutilizes the CPU. The SRM periodically monitors 
the system-wide CPU load to determine whether such imbalances exist. 


The CPU is overutilized if, during the period under consideration, it did not 
enter the wait state, and the lowest priority address space on the dispatching queue 
was not dispatched (constant CCCUTHIT). The CPU is underutilized when its 
utilization is less than a fixed percentage (constant CCCUTLOT). 


The SRM also monitors the CPU usage of individual address spaces. A threshold 
mean execution time before entering the wait state (constant CCCSIGUR) defines 
a heavy CPU user. 


When the SRM determines that a CPU imbalance exists, it searches for heavy 
CPU users and calculates recommendation values for swap out (to correct over- 
utilization) or swap in (to correct underutilization). These values are based on the 
extent to which the CPU load is out of balance. 


I/O Load Adjusting: This function attempts to maintain a job mix that neither 

underutilizes nor overutilizes the system’s logical channels. A logical channel is the 

set of all physical channels (paths) by which a device can be reached. When a : 
request for I/O to a data set is delayed because of a channel busy condition, the J 
delay is caused by the fact that all physical channels of the logical channel are busy. 

Thus the overuse of a physical channel is, in itself, of concern only when that 

physical channel is the only path to a device, and so constitutes the whole of the 

logical channel. 


Each logical channel in the system is periodically monitored to determine 
whether its usage is above or below threshold bounds (constants ICCINHI1 and 
ICCINLO1). Every user in the system is periodically monitored to determine heavy 
I/O users (constant ICCSIGUP). When the I/O load adjusting function determines 
that there is an out-of-balance logical channel (that is, that the use of some logical 
channel falls outside the threshold limits), it recommends the swapping of a heavy 
user of that channel to alleviate the imbalance. The recommendation is based on 
the extent to which the address space makes use of out-of-balance logical channels 
and on the degree to which the channels are out of balance. Note that the percent 
of delayed requests is the control mechanism. 


I/O load adjusting is dependent upon SMF data set activity recording being 
active. The parameter OPT in PARMLIB member SMFPRMxx must be specified 
as OPT=2 if I/O load adjusting is to be operative. 


Enqueue Delay Minimization 


This function deals with the treatment of address spaces enqueued upon system 
resources that are in demand by other address spaces. | ) 
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If an address space controlling a resource is swapped out and that resource is 
required by another address space, the SRM will ensure that the holder of the 
resource is swapped in again as soon as possible. Once in real storage, a swap out 
of the controlling address space would increase the duration of the enqueue bottle- 
neck. Therefore, the controlling address space is given a period of CPU service 
during which it will not be swapped due to service considerations (discussed in 
Section 2). The length of this period is specified by the installation by means of a 
tuning parameter called the Enqueue Residence Value (ERV), contained in 
PARMLIB member IEAOPT xx. 


Device Allocation 


This function attempts to balance the utilization of all logical channels by selecting 
the proper device for allocation to an address space from a list of candidate devices. 
Because VIO satisfies many temporary data sets in MVS, device allocation primarily 
selects candidates for permanent data sets on mountable devices (JCL specifies non- 
specific VOLUME information). 


Device allocation supports the I/O load adjusting function. The former tries to 
equalize logical channel utilization while the latter makes swap recommendations 
to keep logical channel utilization within predetermined bounds. 


The installation’s decisions at sysgen time (the OPTCHAN parameter of the 
IODEVICE macro, DEVPREF on the SCHEDULR macro, and the UNITNAME 
macro) and at IPL time (the number and placement of online mountable devices) 
greatly affect the effectiveness of the device allocation function. 


Since device allocations tend to be made at the beginning of a job’s execution, 
the future impact of that job’s I/O activity on logical channel utilization is not 
known when the allocations are made. Therefore, simply choosing the least 
utilized logical channel would cause all or most allocations for a job to be made to 
the same logical channel. This effect is known as ‘clumping’. The device allocation 
function attempts to avoid this effect by assuming that each data set will have a 
fixed impact on logical channel utilization. Thus, when making an allocation 
choice for a user, a constant (constant ICCEDSUT) is added to the measured 
utilization of a logical channel for each data set previously allocated to the job on 
that channel. 


Prevention of Storage Shortages 

The SRM periodically monitors the availability of three types of storage and 
attempts to prevent shortages from becoming critical. The three types of storage 
are: 

e Auxiliary storage 


@ Pageable frames 
e@ SQA. 
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Auxiliary storage: When more than a fixed percentage (constant MCCASMT1) 
of auxiliary storage slots have been allocated, the SRM will reduce demand for this 
resource by taking the following steps: 





J 


e LOGON, MOUNT and START commands are inhibited until the shortage is 
alleviated. 


e Initiators are prevented from executing new jobs. 


e The number of address spaces allowed in real storage for each domain is set to 
its minimum value (see ‘““Domains”’ in Section 2). 


e@ The address space(s) acquiring this resource at the fastest rate is swapped out. 


@ The operator is informed of the shortage and the name(s) of the job(s) most 
responsible for it is listed, permitting cancellation. 


If the number of available auxiliary slots continues to decrease (constant 
MCCASMT2), the SRM informs the operator that a critical shortage exists. 


When the shortage has been alleviated, the operator is informed and the SRM 
halts its efforts to reduce the demand for auxiliary storage. 


Pageable Frames: When the number of available pageable frames falls below 
a threshold (constant PVTPERFX) due to too many fixed frames, the SRM 
will alleviate this shortage by taking the following steps: 


e LOGON, MOUNT and START commands are inhibited until the shortage is 


alleviated. ) 


e Initiators are prevented from executing new jobs. 


e The number of address spaces allowed in real storage for each domain is set to 
its minimum value (see “Domains”’ in Section 2). 


e The address space(s) holding the greatest number of fixed frames is swapped out. 


e The operator is informed that a pageable frame shortage exists and the name(s) 
of the job(s) most responsible for it is listed, permitting cancellation. 


If the number of fixed pages continues to increase, the SRM informs the 
operator that a critical shortage of pageable frames exists. 


When the shortage has been alleviated (constant PVTPEROK), the operator is 
informed and the SRM halts its efforts to reduce the demand for pageable frames. 


SQA: When the number of available SQA and CSA frames falls below a threshold, 
the SRM will take the following steps: 


e LOGON, MOUNT, and START commands are inhibited until the shortage is 
alleviated. 


e The operator is informed that an SQA shortage exists. 


If the number of available SQA and CSA frames continues to decrease, the SRM 
informs the operator that a critical shortage of SQA space exists. . 
) 


168 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2.03.807) 


Section 2: 


VS2.03.807 


When the shortage has been alleviated, the operator is informed and the SRM 
halts its efforts to prevent acquisition of SQA space. 


(Note: For a discussion of possible operator response to the messages described 
above, see the SRM section, IRAxxxx messages, in the publication OS/VS Message 
Library: VS2 System Messages, GC38-1002.) 


Pageable Frame Stealing 


Pageable frame stealing is the process of taking an assigned frame away from an 
address space to make it available for other purposes. 


When the demand for pageable frames is excessive, the SRM will steal those 
frames that have gone unreferenced for the longest time and return them to the 
system. The Unreferenced Interval Count (UIC) of each frame indicates how long 
it has been since an address space referenced it. This count is updated periodically 
by the SRM. 


Stealing takes place strictly on a demand basis, that is, there is no periodic 
stealing of long-unreferenced frames. 


Introduction to SRM Parameter Concepts 


This section discusses the concepts inherent in the IPS and OPT parameters that 
control the SRM’s distribution of system resources to individual address spaces. 
Parameter descriptions and syntax rules are provided in Section 5 and should be 
referred to when necessary. 


The section entitled “Guidelines and Examples” discusses recommendations for 
the selection of specific parameter values, but these will not be meaningful unless 
the ideas presented in this section are understood. 


Although care has been taken to choose typical numbers for the examples in 
this section, these numbers are not intended as guidelines for actual cases. 


The parameters are presented in the following order: 


domains 

service definition coefficients 
workload levels 

service rates 

performance objectives 
interval service values 
dispatching priorities 
response-throughput bias 
performance periods 
performance groups 


IPS 


resource factor coefficients 
@ enqueue residence values. 


OPT 
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In addition to these parameters, the meaning of terms such as service, service : 
| units, time interval, and transaction is discussed in detail where necessary to } 
support the discussion of related parameters. 





This entire section should be studied as one continuous presentation because the 
ideas introduced under each topic are dependent on the concepts, terms, and 
examples presented under the preceding topic. The examples, for instance, are 
continuously expanded with each newly introduced parameter until, under the 
topic “Performance Group”, a complete IPS has evolved. At that point, the official 
syntax is used for the first time, requiring the reader to refer to Section 5. 


The discussion of OPT concepts is also dependent on preceding topics, that is, 
on IPS parameter concepts. 


It is assumed that the reader is familiar with the basic mathematical concepts 
inherent in the plotting of the relationship between dependent and independent 
variables on a graph. 


IPS Concepts 


The parameters discussed in this part are specified in the IEAIPSxx member of 
SYS1.PARMLIB. 


Domains 


Domains, as discussed under “Domain Control” in Section 1, are a means to J 
differentiate one type of work (or user) from another and thereby make it 

possible to establish different, individually suited, control over different types 

of work. This control is derived from the ability to specify the number of 

address spaces that should be allowed in real storage at one time for a domain. 

This number is called the multiprogramming level, or MPL, of a domain. Via the 

IPS, the installation specifies the desired range for each domain’s multiprogramming 

level, that is, the minimum and the maximum MPL (minMPL and maxMPL, for 

brevity). 


The SRM periodically computes for each domain an optimal MPL called the 
target MPL, adjustable up or down in response to changing activity levels. 


The target MPL is the basis for SRM domain control since it represents the 
actual number of a domain’s address spaces that are allowed in real storage at any 
one time. 


The range of the target MPL is subject to the installation-specified constraints 
(minMPL and maxMPL), that is, it cannot be less than minMPL or greater than 
maxMPL, even when the computed optimal value exceeds these bounds. The 
installation, therefore, has the ability to select the degree of control it wishes to 
exercise over each domain, ranging from complete control to no control at all. 
More control by the installation, of course, implies less control by the SRM. 


Complete control is achieved by setting minMPL equal to maxMPL, resulting 
in a “fixed” target MPL and therefore eliminating the SRM’s ability to make ) 
MPL adjustments in response to changing activity levels. 
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Partial control is achieved by choosing different values for minMPL and 
maxMPL, thereby allowing room for SRM adjustment of the target MPL. 


No installation control at all, or full SRM control, is the result of setting 
minMPL and maxMPL to their extreme values: minMPL = 0 and maxMPL = 255 
(see Section 5 for value ranges). 


Domain Examples: Some basic examples will now be discussed to illustrate the 
purpose and use of domains and the effects achieved by the selection of particular 
constraints. 


Example 1. 


A domain could be created for work that, for reporting purposes, should not be 
mixed with other types of work. For instance, nonswappable address spaces, or 
address spaces associated with different subsystems, could be grouped into unique 
domains. Because the Resource Measurement Facility (RMF) provides workload 
information on a domain basis, placing such work into unique domains provides 
distinction for analysis purposes. That is, it enables the installation to determine 
how much of the total system is being used by a particular nonswappable address 
space, or by a particular subsystem. 


Also, since APG priorities may be assigned to nonswappable address spaces, 
the effects on performance resulting from changes to the dispatching priority of 
such an address space can be evaluated by examining the RMF workload report 
for the respective domain. 


Example 2. 


A domain could be created for work that has particularly fast response time or 
turnaround requirements, such as short (interactive) TSO commands. Placing 
such work into a unique domain with minMPL equal to the maximum number of 
ready users will ensure that each address space is swapped in as soon as it becomes 
ready. That is, forcing the target MPL to be equal to the maximum number of 
ready address spaces guarantees all address spaces of that domain immediate access 
to real storage. 


Example 3. 


A domain could be created for users that might dominate the system. The 
maxMPL value can be used to limit the number of address spaces of this type of 
work allowed in real storage at one time. 


For example, TSO users executing sorts or compiles from the terminal can slow 
down the system considerably. Placing such users into a domain with minMPL = 
maxMPL = 1 would have the effect of serializing such work, since only one address 
space of this type would be allowed in real storage at one time. 


Batch work could be controlled in the same manner. Placing all batch work into 


a unique domain with maxMPL = 2 will limit the number of batch jobs con- 
currently in real storage to two, even if, for example, eight initiators were started. 
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Example 4. 
The MPL adjustment function can set the target MPL of a domain to a maximum J 
that is equal to the average number of ready address spaces plus one, unless pre- 

vented from doing so by the domain constraints. The adjustment function is most 

effective when the arrival rate of work is somewhat consistent, that is, when the 

number of ready address spaces over a time interval does not vary sharply. 


The arrival rate of batch work, for example, is fairly consistent, since it is 
approximately equal to the number of started initiators. TSO work, however, can 
exhibit drastic fluctuations in arrival rate, causing considerable variations in 
response times if the MPL adjustment function is allowed to determine the target 
MPL. 


Consider, for example, a domain with minMPL = 1 and maxMPL = 10. If TSO 
work is arriving at a rate of 10 address spaces every 30 seconds (that is, 10 com- 
mands are entered), the SRM will keep the target MPL near the minimum of 1, 
since, on the average, less than 1 address space is ready every second. Assume now 
that 15 users issue TSO commands at the same tirme. The MPL adjustment function 
does not respond fast enough to this sudden burst of activity since it computes the 
target MPL at fixed intervals, resulting in erratic response times for some of the 
15 users. 


Domain Importance: As discussed in Section 1, the SRM monitors system utiliza- 
tion and periodically adjusts some domain’s target MPL in response to changes in 
the system load. 


An installation has the ability to influence the SRM’s decision as to which J 
domain’s target MPL will be increased or decreased by assigning to each domain a 
weight, or priority, via the IPS domain specification. 


Giving a domain a high weighting factor relative to other domains implies that 
the work assigned to that domain should be given preference when the SRM 
considers the system underutilized and seeks to raise some domain’s target MPL to 
allow more address spaces in real storage. 


The SRM’s decision is based on each domain’s contention index, which is 
computed by the formula: 


average ready users * weight 
target MPL 


contention index = 


The contention index is used as follows: 


1. If the SRM determines that the total number of swapped-in address spaces 
should be increased, it selects the domain that a) has the highest contention 
index, b) has not yet reached its maxMPL, and c) has a target MPL less than or 
equal to its average number of ready users; and increases that domain’s target 
MPL by one. 
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2. If the SRM determines that the total number of swapped-in address spaces 
should be decreased, it selects the domain that a) has the lowest contention 
index and b) has not yet reached its minMPL; and decreases that domain’s 
target MPL by one. 


3. If the SRM determines that the total number of swapped-in address spaces 
should not be increased or decreased, it will attempt to equalize the domains’ 
contention indexes by periodically increasing the target MPL for the highest 
contention domain (thereby decreasing that contention index), and decreasing 
the target MPL for the lowest contention domain. 


Service 


One of the basic functions of the SRM is to monitor the dynamic performance 
characteristics of all address spaces under its control in order to ensure distribu- 
tion of system resources as intended by the installation. 


A fundamental aspect of these performance characteristics is the rate at which 
an address space is receiving service relative to other address spaces competing for 
resources within the same domain. 


Before discussing the meaning of service, a brief explanation of terminology is 
in order to avoid confusion. We have associated performance characteristics with 
address spaces. It is, of course, not the address space that has performance 
characteristics but the transaction associated with the address space. A transac- 
tion is simply the SRM’s way to measure the service consumption within an address 
space, that is, it is a way to delineate a unit of work that is consuming service. 

For batch jobs, a transaction corresponds to a job or job step. For TSO work, a 
transaction normally corresponds to a command. (See Note.) 


Since only one transaction can be active in an address space at one time, and it 
is indeed the address space that is swapped, the use of the term “address space” is 
more convenient when the emphasis of the discussion, for example, is on swapping. 
For the remainder of this section, the two terms will be used interchangeably, 
whichever is more appropriate. 


Note: A new transaction is defined for a batch job step if it is the first step of the 
job, or if the performance group number (PGN, discussed later) is different from 
the previous job step’s PGN. 


A new transaction is defined for an active TSO user whenever 

1. terminal input is entered and the line is not continued; 

2. the 3270 field mark key separates commands on the same input line; 

3. acommand’s output is detained while waiting for a TCAM output buffer. 


Thus, a CLIST is one transaction, unless case 3 applies; every command typed 
ahead on an unlocked keyboard results in a new transaction. 
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The amount of service consumed by an address space is computed by the 
formula: 


service = CPU*CPU Service Units + 
IOC*I/O Service Units + 
MSO*Storage Service Units 


where CPU, IOC and MSO are installation defined service definition coefficients 
and: 


CPU Service Units = task (TCB) execution time, divided by an SRM constant 
which is CPU model dependent. (Refer to “Selecting 
Service Definition Coefficients” in Section 3). 

I/O Service Units = sum of individual SMF data set activity EXCP counts for 


all data sets associated with the address space. 


(real page frames) X (CPU service units) x 1/50, where 
1/50 is a scaling factor designed to bring the storage 
service component in line with the CPU component. 


Storage Service Units 


Service Definition Coefficients 


The service definition coefficients are used to assign additional weight to one type 
of service relative to another, allowing the installation to specify which type of 
resource consumption should be emphasized in the calculation of service rates. 
For example, an IPS may contain the following service definition coefficients: 


CPU=10.0 IOC=5.0 MSO=3.0 


In this case, if an address space has accumulated 100 CPU service units, 200 I/O 
service units and 300 storage service units, its total accumulated service would be: 


(10*100) + (5*200) + (3*300) = 2900 service units 


Service Rate 
The rate at which service is consumed is computed by the formula: 


service 


service rate = ————— 
time interval 


where “‘service”’ is defined by the equation above and “time interval” is a com- 
bination of specific time periods in the life of a transaction that are defined as 
follows: 

Transaction Resident Time — swapped in time 

Transaction Out Time — swapped out (ready) time 


Transaction Long Wait Time — swapped out (not ready) time 


Transaction Active Time — Total Resident Time + Total Out Time 
Transaction Elapsed Time — Total Resident Time + Total Out Time + Total 
Long Wait Time 
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“Time interval” in the service rate formula has two possible meanings: 


a. For aswapped-in address space — 
time interval = last Out Time + current Resident Time. 


b. For aswapped-out address space — 
time interval = last Resident Time + current Out Time. 


If the Out Time is not factored into the time interval, the service rate is referred to 
as absorption rate, 


Example of the calculation of service rate: 


Swap Out Swap In 







Service 
Time t1 t2 t3 t4 t5 t6 t7 


time tl: The transaction is starting. It has not used any service. Therefore, the 
service rate is 0. 


s] 
t2-tl © 
The absorption rate at this time equals the service rate. 





time t2: The service rate equals 


sl + s2 
t3 - tl 





time t3: The service rate equals 


Assume the address space is now swapped out. 


+ 
time t4: The service rate calculated while swapped out is a 
sl] + s2 


time t5: The service rate is ———— . 
t5 -tl 


Assume the address space is swapped back into storage now. The 
service rate is reset to O. 


time t6: The service rate calculated during this in-storage interval is a 
The absorption rate now is ae 
t6 - t5 
: : . si ts4 
time t7: The transaction completes. Its final service rate is TB 


The total service used by the transaction is s] + s2 + s3 + s4, 
Its total resident time is (t3 - tl) + (t7 - t5). 
Its total active time is (t7 - t1). 


Since the transaction did not incur any long wait time, its total elapsed 
time is the same as its active time. 
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Performance Objective and Workload Level 


The service rate, however, is only one aspect of an address space’s performance 2 
characteristics. It does not, for instance, allow consideration of the importance of a 

particular address space. That is, if address space A and address space B are both 

receiving 100 service units per second, this may represent “good” service for 

address space A but “‘bad”’ service for address space B. 


This need for the inclusion of relative importance in the process of comparing 
the service received by competing address spaces leads to the more comprehensive 
concepts employed by the SRM: workload levels and performance objectives. 


A workload level specification consists of a set of positive integers of increasing 
magnitude, such as: 


workload levels = (1,50,100) 


A performance objective consists of a set of service rates and is assigned a 
unique identifier, such as: 


objective 1, service rates = (1000,500,0) 
A performance objective associates a set of service rates with a set of workload 


levels such that there exists, by definition, a workload level number corresponding 
to each specified service rate. The graph of this relationship looks as follows: 


1000 ) 


OBJ 1 
Service 
Rate 


500 


X-axis 
1 50 100 


Workload Levels 


Figure 3-1. Relationship between Workload Levels and Service Rates 


For every service rate on this graph, there is a corresponding workload level. 
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This graph is constructed by the SRM from the workload level numbers and 
service rates specified in the IPS. The specified service rates are used only to 
construct the graph, that is, to draw the line expressing the desired relationship 
between measured service rates and workload levels. The workload levels represent 
a fixed common scale into which an address space’s measured service rate is mapped 
(the purpose of this mapping is discussed later), Thus, the measured service rates 
are the independent variables while the workload levels are the dependent variables. 
(Note that the x-axis in this case represents the dependent variable, contrary to 
conventional usage.) 


Now let us choose a second performance objective: 
objective 2, service rates = (2000,1000,0) 


Figure 3-2 shows this objective plotted against the same workload level numbers 
(there can be only one workload level specification per IPS). 


2000 
OBJ 2 
Service 
- Rate 
1000 
500 
Xx 
1 50 100 


Workload Levels 


Figure 3-2. Comparing the Slopes of Two Performance Objectives 


Now suppose that address space A is associated with performance objective 1 
and address space B with performance objective 2, and that both address spaces, 
at some point in time, are receiving a service rate of 1000. For address space A, the 
corresponding workload level is 1, but for address space B it is 50. 


These numbers, 1 and SO, are the basis for comparing the actual service rates. 
Thus, by associating address spaces with different performance objectives and 
plotting these against a common scale, the importance of each address space is 
factored into the comparison. 


In this case, if address space A is in real storage (swapped in) and address space B 
is waiting to be swapped in, the SRM will assign a swap recommendation value of 
50 to address space B and recommend that an exchange swap be performed (see 
Section 1, Swapping). 
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Consider a third performance objective: 
objective 3, service rates = (2000,2000,2000) 


Since this objective does not end with a zero service rate specification, the 
SRM will extrapolate to determine the zero point, or cut-off level, according to 
the following rules: 


e@ The slope of the last specified segment of the graph is used and that segment is 
extended to the cut-off point (service rate = 0), if possible. 


e The maximum cut-off point is 3/2 of the highest specified workload level 
number. 


For performance objective 3, the cut-off level is 3/2*100=150, resulting in the 
following graph when combined with Figure 3-2: 


OBJ 3 
2000 


Service N 


1000 N 


OBJ 1 N 


1 50 100 150 


Workload Levels 
Figure 3-3, The Effect of Different Performance Objective Slopes on Service 


For any service rate (< 2000) on this graph, address space C, associated with 
objective 3, will have a workload level greater than address spaces A and B. In 
effect, this insulates address space C from exchange swap considerations relative 
to any address space associated with objective 1 or objective 2, within the same 
domain. (The workload level corresponding to a service rate of 2000 for objective 
3 is 100, not 1 or 50.) 


Note that performance objectives are not allowed to slope upward. That is, 


since each succeeding service rate within a performance objective is associated with 
a higher workload level, no service rate may exceed a preceding one. 


Let us now examine how the address spaces of a domain compete with one 
another on the basis of workload levels. 


Consider a domain with a target MPL of 1 and two address spaces, both 


associated with objective 1 of Figure 3-1, and let the abbreviation Adsp1 (obj1) 
denote that address space 1 is associated with objective 1. 
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Assume that Adsp1(obj1) becomes ready first and is therefore swapped in 
with a workload level of 100, corresponding to a service rate of 0. As it begins to 
accumulate service units (see definition of service), its service rate begins to 
increase, causing a corresponding decline in its workload level. Now the second 
address space, Adsp2(obj!), becomes ready and is assigned a workload level of 
100, causing Adsp1(obj1) to be swapped out and Adsp2(obj1) to be swapped in. 
While the workload level of Adsp2(obj1) is now declining, the workload level of 
Adsp1(obj1!) begins to increase again, since its time interval (see definition of 
service rate) continues to increase while it is swapped out and not accumulating 
service units. The result is another exchange swap. 


This exchange between the two address spaces continues until one of them 
completes processing. The frequency of the exchange depends on the rate at 
which the respective workload levels exceed one another and also, of course, on 
the frequency of the SRM’s monitoring of the situation (constant RMPTTOM, 
Section 6). 


Let us now add an address space associated with objective 2 to this domain, 
Adsp3(obj2). Because of the steeper slope of objective 2, the workload level of 
Adsp3(obj2) decreases at a slower rate than the workload levels of Adsp1(obj1) and 
Adsp2(obj!), for corresponding increases in the service rate. The effect is to make 
Adsp3(obj2) more “‘important’’, since it will be kept in real storage for longer 
intervals than its rivals, assuming, of course, a similar rate of consumption of 
service units, and ignoring reasons for swaps other than the workload level (long 
waits, etc.) 


If an address space associated with objective 3, Adsp4(obj3), is included in this 
domain, it can readily be seen that this address space will not be swapped out at all 
until it has completed processing, since its workload level is always greater than or 
equal to the workload levels of the other three address spaces (again ignoring other 
reasons for swaps). 


Figure 3-4 below iilustrates these points and provides a basis for further 


observations. 
Adsp 1(obj1) 
Adsp2(obj1) 
Adsp3(obj2) 
Adsp4(obj3) 
1 2 3 4 5 6 7 8 9 10 


Figure 3-4, Competition for Resources Controlled by Performance Objectives 


The details depicted in Figure 3-4 are arbitrary and depend entirely on such 
variables as the arrival times (that is, when address spaces become ready) and the 
amount of service required by each address space to complete processing. The 
concepts involved, however, will be the same. 
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9: 


The numbers denote the following events: 
Adsp1(obj1) becomes ready and is swapped in with a workload level of 100. 


Adsp2(obj1) becomes ready and is assigned a workload level of 100. Since 
the workload level of Adsp1(obj1) is now less than 99, Adsp1(obj1) is swapped 
out and Adsp2(obj1) is swapped in. 


The workload level of Adsp2(obj1) has now declined to a level below that of 
Adsp1(obj1), which has increased while in the swapped out state. Therefore, 
Adsp1(obj1) preempts Adsp2(obj1). 


Adsp3(obj2) becomes ready and preempts Adsp1(obj1) with a workload level 
of 100. Since the slope of objective 2 is steeper than that of objective 1, 
Adsp3(obj2) will stay swapped in for a longer interval. 


The workload level of Adsp3(obj2) has fallen below that of Adsp2(obj1), 
causing it to be preempted by the latter. 


Adsp4(obj3) becomes ready and preempts Adsp2(obj1) with a workload level 
of 150. It will remain in real storage until it completes because its workload 
level cannot fall below 100. 


Adsp4(obj3) completes processing, allowing Adsp3(obj2) to be swapped in 
again, assuming that it now has the highest workload level. 


Adsp3(obj2) completes and Adsp1(obj1) is swapped in, assuming that it has 
the higher workload level. 


Adsp1(obj1) completes processing, allowing Adsp2(obj1) to be swapped in. 


10. Adsp2(obj1) completes processing. 


Figure 3-4 allows us to make the following observations: 


Address spaces associated with objective 3 can have a serious impact on the 
performance of address spaces associated with objective 1 and objective 2. 

This is especially true if the former represent long-running, batch-like work and 
the latter represent short, interactive TSO commands that require fast response 
times. 


If the reverse is true, that is, objective 3 is used for short TSO commands, and 
these arrive at a fairly regular rate, then the turnaround time for batch work 
may be very unpredictable. 


If batch-like work is associated with the same performance objective as short, 
interactive work, and objective 3 is not used, the long-running work may still 
be severely impacted since regularly arriving short work will constantly preempt 
it with a workload level of 100. 
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e Under the rules of competition described so far, a great deal of swapping takes 
place, causing a corresponding amount of overhead. This would be even more 
apparent if all address spaces were associated with either objective | or 
objective 2. Notice, however, that if objective 3 were the only objective used in 
this domain, swapping would be considerably reduced, due to the fact that much 
greater changes in the service rates would be required to effect similar changes in 
the workload levels. In other words, the frequency of swapping depends directly 
on the slope of the performance objective — the steeper the slope, the less 
frequent the incidence of swapping. 


Note also that the competition for access to real storage is reduced with each 
increase in the target MPL of the domain, assuming a fixed maximum number of 
ready address spaces, and is eliminated altogether if the target MPL is equal to this 
maximum number. 


It is often desirable to exercise a greater degree of control over the competition 
within a domain than is afforded by the use of performance objectives alone. Such 
additional control is provided through another IPS parameter, the interval service 
value. 


Interval Service Value (ISV) 


The purpose of the ISV is to enable an installation to control the frequency of 
swapping. 


This is accomplished by superseding the previously discussed rules for competi- 
tion within a domain for a specific interval, as follows: each time an address space 
is swapped in, it is assigned a service rate of zero, in effect assigning to that address 
space the highest possible workload level for the respective performance objective, 
that is, the cut-off workload level. The ISV specifies the number of service units 
an address space is allowed to accumulate before the workload level corresponding 
to the actual service rate applies. 


To illustrate the use of the ISV, consider again a domain with address spaces 
Adsp1(0bj1), Adsp2(obj1), Adsp3(obj2) and Adsp4(obj3). Assume that each 
address space is associated with an ISV of 400 service units, and that the number of 
service units required by each address space to complete is as follows: 


Adsp1(obj1) — 400 service units 
Adsp2(obj1) — 600 service units 
Adsp3(obj2) — 800 service units 
Adsp4(obj3) — 600 service units 


Figure 3-5 illustrates the effect of the ISV on the competition between these 
address spaces. 
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Figure 3-5. Competition for Resources Controlled by Performance Objectives and ISVs 


1. 


The numbers denote the following events: 


Adsp1(obj1) becomes ready and is swapped in. It remains in real storage for 
the length of its ISV and completes processing without being swapped. 


Adsp2(obj1) becomes ready but does not preempt Adsp1(obj1) since the latter 
is in its ISV, that is, the two workload levels are equal. 


Adsp1(obj1) completes and Adsp2(obj1) is swapped in. 


Adsp3(obj2) becomes ready but cannot preempt Adsp2(obj1), since the latter 
is in its ISV. Notice that the only significant property of an objective, while 
the address space is in its ISV, is its cut-off workload level. The slope of the 
objective has no meaning during this interval. 


Adsp4(obj3) becomes ready and preempts Adsp2(obj1), even though the latter 
is still in its ISV, due to the fact that objective 3 has a cut-off level of 150. The 
ISV, therefore, represents a guaranteed interval of service only when the cut- 
off levels of all objectives in the domain are equal. 


Adsp4(obj3) comes out of its ISV but remains in storage since its workload 
level cannot decrease to less than 100. 


Adsp4(obj3) completes processing and Adsp3(obj2) is swapped in. Notice that 
the service rate is computed in the usual manner while an address space is in 
the swapped out state. Since Adsp2(obj1) has already accumulated service 
units, its workload level is lower than that of Adsp3(obj2). 


Adsp3(obj2) leaves its ISV and is preempted by Adsp2(obj1). 


Figure 3-5 allows us to make the following observations: 


The frequency of swapping can be reduced by using the interval service value. 
Notice that Figure 3-5 shows fewer swapped in intervals than Figure 3-4. 


The ISV is most effective when the cut-off workload levels of all performance 
objectives in a domain are equal. Notice that Adsp4(obj3) causes Adsp2(obj1) 
to be swapped out while the latter is still in its ISV. The reason is the higher 
cut-off level of objective 3, that is, 150 versus 100. 
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@ The effectiveness of the ISV is increased when its value is increased. For 
example, consider the same domain without Adsp4(obj3) and assume an ISV 
of 800. In this case, each of the three address spaces would complete processing 
without exchange swaps. 


The use of the ISV will be discussed again later in this section and also in 
Section 3. 


Up to this point we have discussed three performance characteristics that can be 
associated with an address space: the domain, the performance objective and the 
ISV. A fourth factor has already been discussed in Section 1 — the dispatching 
priority. Once an address space has been swapped into real storage, it competes 
with all other address spaces, regardless of domain, on the basis of the dispatching 
priorities. The higher the dispatching priority, the higher the rate at which an 
address space is allowed to consume resources. Thus, if an installation wishes to 
favor one type of work over another, it can assign a high dispatching priority in 
addition to favorable domain constraints, performance objectives and interval 
service values. 


Response — Throughput Bias (RTB) 


A swap recommendation based on the workload level of an address space is one of 
three possible factors contributing to the SRM’s exchange swap decisions. The 
other two are recommendations from the CPU and I/O load adjusting functions 
(see ‘““Functions’’, Section 1). 


An installation can specify whether the latter two recommendations should be 
considered or not via the RTB parameter in the IPS. In addition, these load 
adjusting recommendations can be given a desired weight, or importance, via the 
resource factor coefficients in the OPT (see “OPT Concepts” in this section). 


The RTB has only two possible values: zero and one. If the RTB is set to zero, 
the workload level recommendation is the sole basis for exchange swap decisions. 
The effect of this choice is to emphasize good response time as opposed to system 
throughput considerations, since system load adjusting recommendations will be 
ignored. 


If the RTB is set to one, the CPU and I/O load adjusting recommendations are 
factored into the exchange swap decisions (see “OPT Concepts’’). Since these 
recommendations can be weighted, an installation may specify, for instance, that 
under certain conditions an address space may “hog” the CPU, even though this may 
result in a degradation of response time for all other address spaces. In effect, 
setting RTB to one means that swap recommendations should be made in the 
interest of throughput, not response time. 
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Performance Period 


In the preceding examples, each address space has been associated with one set of 3 
performance characteristics from the time it becomes ready until processing is 

completed. Additional flexibility of control is gained by dividing this life span into 

distinct performance periods, and associating an address space with a different set 

of performance characteristics for the duration of each period. This ability is 

provided via the IPS. 


The purpose of performance periods is to allow an installation to vary the 
performance characteristics of transactions as their execution characteristics 
change. For example, if a domain includes a variety of TSO users, transactions 
with greatly differing life spans will be competing with one another. If the 
majority of transactions are of short duration and these are to experience con- 
sistently good response time, it may not be satisfactory to keep one set of per- 
formance characteristics in effect for the entire life span of every transaction. By 
using performance periods, short transactions, for instance, can be favored over 
long transactions without prior knowledge of individual life spans. The following 
example illustrates this concept. 


Consider a TSO domain with a variety of transactions whose life spans range 
from short to intermediate to long, where: 


short is < 400 service units, 
intermediate is > 400 and < 2000 service units, 
long is > 2000 service units. 


Assume that three sets of performance characteristics have been defined, as ) 
follows: 


Set 1: TSO domain, objective 3, ISV=400 service units, dispatching priority = 
7E, RTB=0 


Set 2: TSO domain, objective 2, ISV=2000 service units, dispatching priority = 
7D, RTB=0 


Set 3: TSO domain, objective 1, ISV=2000 service units, dispatching priority = 
76, RTB=0 


Assume also that three performance periods have been defined, such that Set 1 
is in effect during Period 1, Set 2 is in effect during Period 2, and Set 3 is in effect 
during Period 3, for all transactions in the TSO domain, and that the length of each 
period is as follows: 


Period 1: 400 service units 


Period 2: 1600 service units 
Period 3: to end of transaction 
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Each transaction, therefore, is associated with the following composite set of 
characteristics: 


Set 1 for the first 400 service units, or to end of transaction 
Set 2 for the next 1600 service units, or to end of transaction 
Set3 to end of transaction. 


Such a composite set of performance characteristics, consisting of one or more 
performance periods, is called a performance group. A transaction is associated 
with a performance group Via the latter’s unique identifier, the performance group 
number. 


Performance Group 


The performance group is the vehicle that enables an installation to associate a 
user’s transaction(s) with a set of performance characteristics for each point in the 
life of the transaction(s), and thus to specify the treatment it wishes a job, job 
step, or time-sharing session to receive at all times. Batch job steps and TSO 
terminal sessions are associated with a performance group by the specification of 
a performance group number (PERFORM=nnn) on the JOB or EXEC statement, 
on the LOGON command, on the RESET command, or by default. (See 
**Assigning Performance Group Numbers” in Section 4.) 


Let us now collect the specifications used so far in this section into a complete 
IPS, using the official syntax as described in Section 5: 


CPU=10.0 IOC=5.0,MSO=3.0 
WKL=(1,50,100) 


OBJ=1,SRV=(1000,500,0) 
OBJ=2,SRV=(2000,1000,0) 
OBJ=3,SRV=(2000,2000,2000) 


DMN=1 ,CNSTR=(1,2,1) 
DMN=2,CNSTR=(4,8,10) 


PGN=1,(DMN=1 ,OBJ=1 ,ISV=400, ...) 
PGN=2 ,(DMN=1 ,OBJ=2,ISV=400, ...) 
PGN=3 (DMN=1 ,OBJ=3 ,JSV=400 , . . .) 


PGN=4,(DMN=2,0BJ=3,ISV=400,APG=14,RTB=0,DUR=400) 
(DMN=2,0BJ=2,ISV=2000,APG=13,RTB=0,DUR=1600) 
(DMN=2,OBJ=1 ,ISV=2000,APG=6,RTB=0) 


where: 


Domain 1 (DMN1) is the domain used for the examples illustrated by Figure 3-4 
and Figure 3-5; 


Domain 2 is the TSO domain described under “Performance Period”’; 


Performance groups 1, 2 and 3 (PGN1,. .) represent the partial sets of 
characteristics illustrated by Figure 3-5; 


Performance group 4 is the composite set described under “Performance Period”’. 
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We now return to the discussion of the TSO domain and performance group 
PGN4. The following observations can be made about transactions competing in 
this domain: 


e@ During Period: 1, all transactions are associated with performance objective 
OBJ3, which represents relatively “good” service (see Figure 3-3), and a high 
APG priority of 7E (70 + E = 7E (HEX)). An ISV of 400 ensures that no 
exchange swapping takes place at all during this period, since this value is equal 
to the duration of the period. Note again that each specification is in effect only 
for the duration of the respective period. 


e Transactions requiring more than 400 service units are then switched to the less 
favorable performance objective OBJ2 (a lower cut-off level), and a lower 
dispatching priority of 7D. 


e@ Transactions requiring more than 2000 service units are then switched to 
objective OBJ1, and the mean-time-to-wait APG priority (see “Functions”, 
Section 1). 


e Under these conditions, intermediate and long commands (transactions com- 
pleting during Period 2 and Period 3, respectively), will probably exhibit poor 
response times during periods of high terminal activity. Notice that trans- 
actions in Period 1 will preempt those in Period 2 and Period 3 even when the 
latter are in their ISV interval (see Figure 3-5). To prevent swapping during ISV 
intervals, the cut-off workload levels of the performance objectives must be 
equal, as in the following performance group (PGN 4 without objective OBJ3): 


PGN=5, (DMN=2,O0BJ=2,....) 
(DMN=2,0BJ=2,... .) 
(DMN=2,OBJ=1,....) 


Under the conditions of performance group PGNS, the response time of short 
commands may become erratic since transactions in Period 2 and Period 3 now 
have a much higher chance of gaining access to real storage. This problem may be 
alleviated somewhat by decreasing the ISV for Period 3 to 1000 service units. 
Another solution would be to remove transactions entering Period 3 from the 
domain, as follows: 


PGN=6, (DMN=2, ... .) 
(DMN=2, ....) 
(DMN=1,....) 


It should be remembered that the purpose of the examples in this section is to 
illustrate concepts, not to serve as recommendations. 


This completes the discussion of IPS concepts. 
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OPT Concepts 


The parameters discussed in this part are specified in the IEAOPTxx member of 
SYS1.PARMLIB. 


Resource Factor Coefficients (RFC) 


The purpose of the resource factor coefficients is to enable an installation to assign 
the desired weight to the swap recommendation values produced by the CPU and 
I/O load adjusting functions (See ‘“‘Resource Use Functions’, Section 1). If the 
response-throughput bias (RTB) in the IPS is set to one, the SRM will combine 
these weighted values with the workload level recommendation to determine the 
full swap recommendation value of an address space. This combined value is the 
basis for exchange swap decisions. It is computed by the following formula: 


swap recommendation value = 
workload level recommendation 
+ (CPU coefficient * CPU load adjusting recommendation) 
+ (1/0 coefficient * I/O load adjusting recommendation) 


Setting either coefficient to zero eliminates that recommendation from con- 
sideration. Setting both coefficients to zero is equivalent to a specification of 
RTB=0 in the IPS. 


The values generated by the load adjusting functions depend on the total CPU 
and I/O imbalance and on the percentage of that imbalance caused by a particular 
address space. Although the computations involved are beyond the scope of this 
discussion, the effects of specific coefficients on swap analysis can be studied by 
considering the maximum possible load adjusting values. These values are limited, 
by definition, to 1/5 of the highest cut-off workload level of all performance 
objectives. 


For example, if the highest cut-off level is 100, the maximum CPU load 
adjusting recommendation value will be (1/5*100)=20. 


Consider an IPS with WKL=(1,100) and a performance objective with 


SRV=(500,0). The following graph illustrates the range of variations in the swap 
recommendation value due to a CPU coefficient of 1. 


500 


Service 
Rate 





1 80 100 120 
Workload Level 


Figure 3-6. The Effect of RFCs on Swap Recommendation Values. 
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Figure 3-6 allows the following observations: 


e An increase in the resource factor coefficients causes a corresponding decrease 
in the effect of workload level recommendations on exchange swap decisions. 


e High resource factor coefficients can lead to a loss of control over the 
frequency of swapping, achieved via the interval service value (See Figure 3-5). 
That is, the differences in the swap recommendation values of address spaces 
will be such that the frequency of exchange swaps could approach a level 
equivalent to no ISV control. 


These two observations indicate that care must be taken in selecting the co- 
efficients, and that any positive effect achieved through their use should be 
balanced against the possible negative impact on workload level control. 


e@ The SRM assigns either a positive or negative sign to the load adjusting 
recommendation values, depending on the particular imbalance. For instance, 
if the CPU is underutilized, it will select ready address spaces that are heavy 
CPU users and add the load adjusting value to their workload levels to increase 
their chances of getting swapped in. If the CPU is overutilized, the SRM will 
select swapped in address spaces that are heavy CPU users and subtract the load 
adjusting value from their workload levels to increase their chances of being 
swapped out. 


Resources Manager Constant (RMC) 
The purpose of the Enqueue Residence Value (ERV) is discussed under ““Enqueue - 
Delay Minimization’’, Section 1. 
Section 3: Guidelines and Examples 
This section discusses guidelines for: 
e Defining installation requirements and objectives 
e Selecting values for IPS and OPT parameters 


e Evaluating and adjusting these values. 


In addition, the default IPS and several IPS variations are presented and 
explained. 


An installation’s individual needs and requirements may lead to ultimate 


specifications that differ greatly from the values presented here. The guidelines 
should, nevertheless, prove useful as a starting point. 
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Defining Installation Requirements 


Before specifying any parameters to the SRM, an installation must define response 
and throughput requirements for its various classifications of work. 


Examples of specific questions that should be answered are listed below. The 
applicability of these questions will, of course, vary from installation to installation. 


Subsystems 


How many subsystems will be active at any one time and what are they ? 
For IMS or VSPC, how many active regions will there be ? 
Will the subsystem address space(s) be nonswappable ? 


What is the desired response time and how will it be measured ? 


Batch 


What is the required batch throughput or turnaround for various job classes ? 
Are jobs being placed in the correct class ? 


This is an important question. The MVT scheme of job classing may not be 
appropriate in MVS because of differences in storage usage. 


How much service do these jobs require, and what service rate is needed to meet 
the turnaround requirement ? 


The MF/1 workload report or reduction of SMF data in type 5 records will 
provide the average service consumed by jobs of different classes, For 
installations new to MVS, the following suggestion is offered based on service 
definition coefficients of CPU=10.0, IOC=5.0, MSO=3.0: 


Quick jobs use 10,000 service units or less. 
Medium jobs use between 10,000 and 30,000 service units. 
Long jobs use 30,000 units or more. 


What is the average number of ready jobs ? 


Most likely, this is the number of active initiators. In MVS, the number of 
initiators in real storage may be less than the number of MVT/SVS initiators. 
A few extra initiators may be started to decrease turnaround times. 


TSO 


What is the number of terminals ? 
What is the average number of ready users ? 


As a guideline for installations new to TSO, assume two ready users for every 
ten users logged on. This average will depend on the type of terminal and on 
the type of TSO session (data entry, problem solving, program development). 
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What is the required response time and expected transaction rate for different 
categories of TSO transactions at different times, such as peak hours ? J 
What is the expected response time for short transactions ? 

How will this response time be measured ? 

Should response time be different for select groups of TSO users ? 

How should semi-trivial and non-trivial transactions be treated ? 


How are they defined ? 


An installation using MVS will have MF/1 Workload Reports or SMF data in 
type 34 and 35 records available to help define trivial and non-trivial TSO 
work. For those installations with no previous MVS experience, the following 
suggestions may serve as guidelines, again based on service definition 
coefficients of CPU=10.0, IOC=5.0, MSO=3.0: 


Short TSO commands use 600 service units or less. 
Medium length commands use between 600 and 2,000 service units. 
Long TSO commands use 2,000 service units or more. 


What is the required service rate for TSO users ? 


If 2-second response time (asreported by MF/1) is required for very short TSO 
commands (100 service units), the required service rate for such a transaction 
is 100/2 or 50 service units per second. Service rates for other types of trans- 
actions should be computed also. 


General 


What is the importance level of TSO, batch, IMS, and special batch classes in 
relation to one another ? 


Which may be delayed or “‘tuned down” to satisfy other requirements ? 

In other words, which response requirements are fixed and which are variable ? 
What percentage of system resources should each group receive ? 
How critical are certain resources — especially the CPU and channels ? 


If a user makes heavy demands on a resource, the installation will have to 
decide whether the user’s response time requirement should be waived in favor 
of a more balanced system load. 


Once these questions have been answered, and the installation is somewhat 


confident that its requirements can be met by the hardware, the installation is 
ready to begin writing an initial IPS and OPT. 
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Preparing an Initial IPS and OPT 


This section presents guidelines for selecting IPS and OPT parameter values. Where 
applicable, values are given which may be used as initial values when no previous 
performance data is available. 


There are three approaches to preparing an initial IPS and OPT: 


1. Use the default IPS and OPT 
2. Modify the defaults 
3. Create a new IPS and/or OPT. 


It is suggested that installations new to MVS initially use the default IPS 
(IEAIPSO0) provided with the system. This also applies to installations using the 
default IPS provided with Release 2 and 3 of OS/VS2. (See “‘Default IPS” in this 
section.) 


Installations that have modified the default IPS provided with release 2 or 3 of 
MVS and created new PARMLIB members should consider replacing these, due to 
different functional characteristics of the new SRM. 


Work Sheets: If an installation decides to modify the default IPS or create a new 
IPS, the following worksheets may be of value while reading this section. They 
have been included as an aid for recording parameters and values as they are 
defined. After concluding this section, the completed work sheets should enable an 
installation to write an IPS, in formal syntax, with a minimum amount of effort. 
(In most cases, only a subset of the available entries will be needed). 
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Worksheet Number 1 — Service Definition Coefficients 
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Worksheet Number 3 — Execution Characteristics Definition 


Objective Number Comments 


Duration ISV Value 


Subclass 


Class 


“y “y 
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Worksheet Number 4 — Objective Control Per Domain 
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Worksheet Number 5 — Performance Group/Period Definition 
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Selecting Service Definition Coefficients (Worksheet Number 1 ) 


The purpose of the service definition coefficients (SDCs) is to allow the individual 
service components to be weighted. For example, there will probably be a greater 
demand for the resource in least supply. Using the coefficients, service provided by 
such a resource can be given added importance. This is not to imply that the 
service values are to be used for accounting purposes, since, as will be seen later, the 
service consumed by a job is not necessarily repeatable. 


The coefficients should be high enough to yield a range of service rates 
sufficiently high for the workload management function to be effective, but they 
must not be so high that service rates become excessively large. This also results in 
ineffective workload management control. 


Changes to the coefficients may necessitate changes to other parameters in the 
IPS that are dependent on service value specifications (for example, interval service 
value and duration). 


An increase in a service definition coefficient will numerically raise the system 
service capacity and the service rate of users, though not, of course, affecting the 
system’s physical capacity for work. 


For example, consider the I/O component of service for the following: 


e With IOC=1.0, a service rate of 100 represents 100 I/O requests/second. 
e With IOC=2.0, a service rate of 100 represents 50 I/O requests/second. 


Three alternatives exist for setting the SDCs: 


1. Use the values in the default IPS (IEAIPSOO). These should generate reasonable 
service values for the workload management function. 


The default coefficients are: 


CPU=10.0 
IOC=5.0 
MSO=3.0 


2. Use previous installation SDCs. The installation may wish to modify the 
coefficient for main storage usage. A coefficient of 1 to 3 should have a 
minimum effect on IPS parameters that are dependent on service value specifica- 
tions. 


3. Define new coefficients. To do this, a more detailed understanding of the 


individual service components is required. These are discussed separately in the 
following paragraphs. 
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CPU Service: The SRM calculates CPU service based on task execution time and 
CPU model, which should make the IPS independent of the CPU model. 





J 


The following table describes the CPU service consumed per second of task 
execution time by CPU model. The values listed are internal SRM constants. The 
“total system absorption rate” reported by RMF will not equal the values listed 
here because these do not include SRB-mode processing and certain other types 
of system processing. 


Service Units Per Seconds of Task 
Second of Task Execution Time Per 
CPU Model Execution Time Service Unit 
145 24.0 .0417 
155 42.0 .0238 
158 51.2 .0195 
165 125.0 .0080 
168 151.0 .0066 


For installations with no prior service data the task time reported in type 4, 5, 
34, and 35 SMF records could be converted to service units using the above table. 


CPU time may not be identical for different runs of the same job step. One or 
more of the following factors may cause small variations in CPU time: CPU 
architecture (such as storage buffering), cycle stealing with integrated channels, and 
the amount of queue searching (see the publication OS/VS2 SPL: System 
Management Facilities (SMF), GC28-0706). J 


I/O Service: One I/O service unit corresponds to one EXCP, as reported by SMF. 
The EXCP count does not include EXCPs issued by a program in system key. 
Hence, EXCP counts are not maintained for IMS. Note that the count maintained 
by the SRM wraps around at 65,536. It is reset at every swap analysis, swap out 
and job step termination. Nonswappable address spaces may exhibit erroneous 
counts because of these factors. 


For a description of SMF EXCP counts, refer to the publication OS/VS2 SPL: 
System Management Facilities (SMF), GC28-0706. 


Main Storage Service: A program uses one storage service unit when it holds 50 
pages (200K) for one CPU service unit. The amount of storage service available 
can be determined by calculating the number of pages available for problem 
program use (from RMF paging reports) and applying the following formula: 


# pages* #CPU service units 


storage service units = 50 
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This formula has been simplified to allow the presentation of an example (see 
below). In the actual calculation, the SRM utilizes a continually updated variable 
called page seconds. This variable is the product of task execution time and the 
number of frames allocated to an address space, and it is updated every time the 
number of frames changes (due to page faults, stealing). The page seconds 
accumulated by a transaction are reported in SMF type 4 and 34 records. 


The main storage component of service can affect the repeatability of service 
required by a transaction, since the total storage service available varies with the 
number of address spaces in real storage at any one time. 


For example: 


Assume 100 pages and 10 CPU service units are available for problem program 
usage. 


Case I: 1 address space uses all 100 pages for the entire amount of time (10 
CPU service units). 


The total amount of main storage service used would be: 


100 * 10 ; 
3. = 20 storage service units 
Case 2: 2 address spaces share the resources equally. That is, each address space 


uses 50 pages for 5 CPU service units. 
The total amount of main storage service used by each address space would be: 


50*5 ; 
50. 5 storage service units 





Since each address space used 5 storage service units, the total number of units used 
is 10. All pages and CPU services were used, and yet the total is less than in Case 1. 
Thus, the service rate for an address space decreases as the number of executing 
address spaces increases. 


Once it is known how many CPU, I/O and storage service units are available, the 
coefficients can be selected to weight each service component. For example, if the 
intent is to equalize the importance of the service components, the coefficients may 
be determined by using the equations: 


CPU * CPU service units = IOC * I/O service units = MSO * storage service units 


Selecting a reasonable value for one coefficient, such as 10 for CPU, allows 
calculation of the other two values. 
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Defining Domains and Their Constraints (Worksheet Number 1) 





The following suggestions for defining domains are based on separating an installa- 
tion’s work into four general classifications: 


Subsystems 
Batch 

TSO 

Special purpose 


Each classification is discussed separately. It should be noted that as execution 
characteristics change, address spaces may be reclassified. For example, very long 
(to be defined later) TSO commands may be reclassified as batch work. 


Guidelines are presented for selecting appropriate MPL values and weights for 
each type of domain. (Note that minimum MPL values should not be set too high. 
This may cause excessive paging overhead.) 


Subsystem Domains: Domains should be defined for each separate subsystem, such 
as IMS, CICS, VSPC, etc. Associating a subsystem’s address space(s) with a unique 
domain is useful because it enables RMF to report the service used by that sub- 
system. 


Normally subsystems will be nonswappable due to the undesirability of incurring 
swapping overhead. Other reasons may also exist for making subsystem address 
space(s) nonswappable. For example, the IMS 1.1.1 resource serialization - 
technique does not cause an address space holding a serialized resource to be 
swapped in should some other address space require that resource. 


MPL specifications for domains of nonswappable subsystem address spaces have 
no meaning, since nonswappable address spaces are not counted by the SRM when 
determining the current MPL for a domain. 


MPL specifications for domains of swappable subsystem address spaces should 
allow instant swap in of these address spaces when they become ready. Therefore, 
the minimum MPL should be greater than or equal to the number of address spaces 
associated with the subsystem. The maximum MPL value is not meaningful in this 
case. Since the MPL adjustment function is not utilized for subsystem domains 
with these recommended MPL values, the weight of such domains should be 
set to 1. 


Batch and TSO Domains: There are crucial differences between the execution 
characteristics of batch and TSO work, such as the amount of service required to 
complete processing and the arrival rate of work. Batch jobs usually require con- 
siderably more service than most TSO commands and could therefore overload the 
system if the number of such jobs allowed in real storage were not controlled. Such 
limits, however, are not desirable for most TSO work. Since this control is achieved 
via the domain constraints, the two different requirements cannot be satisfied by 
one domain. Therefore, separate domains should be created for batch and TSO 


work. ) | 
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In most cases, one domain should be sufficient for batch work. Performance 
objectives can be used to achieve the desired degree of control over individual jobs. 


If all TSO commands require uniform service, one domain will probably suffice 
to provide good response time. However, if the TSO work consists of commands 
with diverse service needs, that is, both short and long-running commands, 
additional domains may have to be defined in order to satisfy these different 
requirements. 


As discussed in Section 2, the maxMPL value is used to limit the number of 
address spaces allowed in real storage, while the purpose of the minMPL is to 
guarantee access to real storage for a fixed minimum number of address spaces. 


The minMPL value can be used to implement fixed response requirements. If 
fast response, for example, is a fixed requirement for short TSO commands, the 
minMPL value should be set to 1 or 2 for every 10 logged on users. For instance, 
if 40 users are logged on, a minMPL value of 4 would be a good starting point. 


For batch work, if there are no fixed throughput requirements, the SRM should 
be allowed to determine the target MPL in a range of 0-255. If, however, a specific 
number of jobs must be processed during a particular period of time, the minMPL 
should be raised slightly above zero (1 to 3) in order to guarantee access to real 
storage for some minimum number of batch jobs. 


For long-running, batch-like TSO commands, the maxMPL value should be used 
to limit the number of such commands in real storage. This is advisable since such 
commands, although batch-like, do not have a predictable arrival rate and may 
therefore overload the system. A minMPL of 1 and maxMPL of 2 might be 
appropriate if such control is desired. 


Domain weights have meaning only for domains whose target MPL is adjustable, 
and only when there is more than one such domain. Domains with fixed target 
MPLs should be given a weight of 1. 


Domain weights have the effect of creating an ordered priority list according to 
which the SRM decides which domain’s target MPL should be raised or lowered 
first. The differences between weight values should be sufficiently large to ensure 
that the computed contention indexes (see Section 2) actually reflect the 
installation’s intentions. These indexes may be calculated beforehand by using 
representative values, as suggested by the following method: 


For batch, assume that the average number of ready users is equal to the 
number of initiators and that the target MPL is 1. 


For TSO, assume that the average number of ready users is equal to the 
target MPL, resulting in a contention index equal to the weight. 


For example, assuming there are 8 initiators, the contention indexes would be: 


TSO contention index = TSO weight 


batch contention index = 8 * batch weight 


Therefore, if the TSO domain is to be favored over the batch domain, the weight 
for the TSO domain must be more than 8 times the batch domain weight. 
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Notice that the weight has no meaning when the minMPL is sufficiently high to 


eliminate MPL adjustment, as recommended for TSO domains with fast response 
requirements. The weight may be used, however, to favor batch work over long- 
running TSO work if both types are in unique domains. 


Special Purpose Domains: A separate domain may be created to prevent ready 
work from executing. For example, the system operator may halt the execution 
of a job by associating it with a domain having a fixed target MPL of zero, that is, 
minMPL = maxMPL = 0. 


Selecting Dispatching Priorities (Worksheet Number 2) 


The following recommendations are made for the selection of dispatching 
priorities: 


Address spaces with no fixed requirements, possibly long TSO transactions and 
long batch jobs, should be assigned to the mean-time-to-wait group of the APG 
to aid throughput. 


Address spaces that are likely to be CPU-bound should be assigned to the mean- 
time-to-wait group. When such an address space is executing (that is, looping), 
no address space with a lower priority can be dispatched. The mean-time-to-wait 
group allows the SRM to dynamically adjust the dispatching priority. 


The IMS control region should be assigned a high dispatching priority, possibly 
lower than that of TCAM, but higher than the dispatching priorities of initiators 
and short TSO transactions. 


The dispatching priorities of IMS message processor regions (MPRs) will depend 
on whether any work assigned to the APG should be favored over these MPRs. 
If, for example, short TSO transactions are to be favored over IMS MPRs but 
long TSO transactions are not, then the IMS MPRs must be assigned to the APG. 


Initiator dispatching priorities should be lower than those of short TSO trans- 
actions (first period transactions) and IMS MPRs, but probably above the 
mean-time-to-wait range in order to ensure fast allocation. 


The Rotate dispatching priority of the APG should be used to prevent one sub- 
system address space from dominating another. 


Note again that for nonswappable address spaces only the priority specified in 
the first period of the associated performance group is applicable. 
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Defining Durations (Worksheet Number 3) 


Durations may be used to subdivide a major class of work into subclasses. For 
example, transactions may be subdivided into short, medium and long. Examples 
of possible subdivisions by duration are shown in the following table. The values 
are those used in the default IPS (IEAIPSOO). 


(Note: Duration may be specified in real time units. However, this is not recom- 
mended except in special cases which will be discussed later). 


ee eee 
(Service Units) 
edu | e000 30000 


A subclass, in these examples, corresponds to a performance period, with the 
duration value defining the length of the period. The service units required by TSO 
sessions and batch jobs are reported in SMF type 4, 5, 34, and 35 records. An 
installation may use this data to define appropriate subclasses. For batch jobs, 
duration values may be selected to reflect initiator classes. 












Selecting ISV Values (Worksheet Number 3) 


As discussed in Section 2, ISV values are used to control the frequency of swapping. 
An increase in ISV values reduces the number of exchange swaps. The effectiveness 
of ISV control over swapping is reduced if multiple performance objectives are used 
in a domain and these have different cut-off levels. 


When duration specifications exist, ISV values for the respective periods will 
depend directly on the duration values. For example, if short TSO transactions 
have a duration of 600 service units and control swaps are to be prevented during 
this interval, the ISV value must be at least 600 service units. If an ISV value of 
20,000 were associated with short batch transactions (see table), no swaps would 
occur during that period, since the transaction would switch periods after 10,000 
service units. If the ISV value were set to 5000, one control swap would probably 
occur after 5000 service units, provided, of course, that other address spaces of the 
domain are ready to be swapped in. 


ISV values are not meaningful for non-swappable address spaces and for domains 


whose minMPL is sufficiently high to allow all its ready address spaces to be 
swapped in at one time. 
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Selecting Performance Objectives (Worksheet Number 4) ) 


It is recommended that new performance objectives be defined. Previously defined 
objectives may no longer serve their intended purpose due to the functional 
differences of the new SRM. 


To draw a performance objective, workload level numbers and service rates must 
be selected. For recommended workload level numbers, refer to ‘“‘Default IPS” and 
“IPS Examples.” 


An appropriate set of service rates should take into consideration the total 
available system service as described under “Selecting Service Definition 
Coefficients.” For example, assume a model 158 4-megabyte system with 300 
EXCPs/second and 640 pages for problem program use. Using the default SDCs of 
CPU=10.0, IOC=5.0, MSO=3.0, the maximum service available would be: 


(10.0*51.2) + (5.0*300) + (3.0%640*51.2/50) = 3978 


Since only a fraction of this total is available to any single address space, a 
service rate of 1000 to 2000 would be a reasonable upper limit for performance 
objectives for this configuration. 


Adjustments may be necessary after analysis of RMF workload reports showing 
the absorption rates of individual performance objectives. If the absorption rate 
of an objective approaches the maximum specified service rate, that objective 
should be redefined with a higher maximum service rate. 


The following points should be considered when defining performance J 
objectives: 


e Should the cut-off workload level be equal to that of other objectives of the 
same domain, or should address spaces be preempted while in their. ISV 
interval ? For example, especially important batch jobs may be associated with 
an objective that allows them to preempt all other jobs in the domain. 


e The slope of an objective is not meaningful when all transactions in a domain 
complete processing within their ISV interval. 


e Drawing a steeper slope will cause recommendation values for swapped in 
address spaces not in their ISV to decrease less rapidly, thereby allowing more 
service to be accumulated prior to swapping. The steeper the slope of the 
objective, the less swapping will be incurred. 


@ Objectives should be kept simple. 
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For batch work, two objectives may provide the initial desired degree of control, 
while one objective may be sufficient for TSO work. Suggested variations for both 
types are described under “IPS Examples”. One possible variation of the use of 
Objectives is illustrated below. 


1000 


OBJ 1 


500 
OBJ 2 


1 99 100 


Figure 3-7. A Use of Different Cut-off Levels 


Explanation: 


Workload levels must differ by more than 1 to cause an exchange swap. Therefore, 
address spaces associated with the lower objective will not be preempted by address 
spaces associated with the highter objective while in their ISV intervals. That is, 
ISV preemption will not occur even though the cut-off levels of the two objectives 
are different. 


If, however, the MPL adjustment function were to decrease the target MPL of 
this domain, the lower cut-off level of objective 2 would cause an address space 
associated with that objective to be swapped out. If the cut-off levels were equal, 
an address space associated with objective 1 would have the same chance to be 
selected for swap out. 


This combination of objectives, therefore, accomplishes a dual purpose — ISV 
preemption is avoided, and the intended function of the higher objective is 
preserved. 


The RTB Parameter and the Resource Factor Coefficients 


It is recommended that the RTB be initially set to 0. Possible cases when the RTB 
should be set to 1 are discussed under “Evaluating and Adjusting the IPS and 
OPT”. 


The RTB function is useful only when CPU or logical channel utilizations are 


significantly out of balance. Under normal circumstances, an RTB specification of 
1 will cause unnecessary overhead without accomplishing anything. 
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values are added to workload level recommendations. The resultant differences in 
swap recommendation values may be large enough to cause a loss of control over 
the frequency of swapping, that is, ISV control of swapping may no longer be 
effective. 


Also, as discussed in Section 2, the CPU and I/O load adjusting recommendation ) 


Performance Groups (Worksheet Number 5) 


Reasons for assigning unique performance group numbers vary from installation to 
installation. The following are possible candidates for unique numbers: 


Each subsystem 

Individual subsystem address spaces 
Groups of users 

Departments 

Batch initiator classes 

Monitor programs 


For batch work, the default performance group number is 1. For TSO, the 
default number is 2. These two performance groups must be specified in every 
IPS. 


Default IPS 


The default IPS is based on the guidelines just presented. However, not all specific J 
recommendations where used because this IPS must be acceptable for any CPU, 

storage, and I/O configuration. The philosophy of this default IPS is to provide 

highest priority (best response) to short TSO commands, then medium TSO 

commands, then long TSO commands, and to detain batch jobs whenever TSO 

service needs to be increased. 
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Domain Number 2 Domain Number 3 
1000 

1 50 99 100 1 50 99 100 
CPU=10.0, |OC=5.0, MSO=3.0 /* DEFAULT IPS — IEAIPSOO =) 

WKL=(1,50,99,100) 
OBJ=1,SRV=(1000,*,*,0) /* FIRST PERIOD BATCH (DMN 1) */ 
OBJ=2,SRV=(1000,* ,0) /* SECOND PERIOD BATCH (DMN1) ty 
OBJ=3,SRV=(1000,*,*,0) /* FIRST PERIOD TSO (DMN2) */ 
OBJ=4,SRV=(1000,*,*,0) /* SECOND PERIOD TSO (DMN2) af 
OBJ=5,SRV=(1000,*,*,0) /* THIRD PERIOD TSO (DMN3) */ 
OBJ=6,SRV=(1000,1000,1000, 1000) /* HOT BATCH (DMN 1) ay 
OBJ=7,SRV=(1000,1,0) /* LOW PRIORITY BATCH (DMN 1) =) 
DMN=1,CNSTR=(1,50,1) /* BATCH */ 
DMN=2,CNSTR=(1,50,255) /* SHORT AND MEDIUM TSO af 
DMN=3,CNSTR=(1,50,16) /* LONG TSO */ 
PGN=1, (DMN=1,APG=6,DUR=10K ,ISV=10K OBJ=1,RTB=0) /* BATCH -SHORT */ 
(DMN=1,APG=6,ISV=10K ,OBJ=2,RTB=0) /* —--—-+- MEDIUM */ 
PGN=2, (DMN=2,APG=14,DUR=600,ISV=600,0BJ=3,RTB=0) /* TSO -SHORT */ 
(DMN=2,APG=13,DUR=1400,ISV=2K OBJ=4,RTB=0) /* ———-— - MEDIUM *} 
(DMN=3,APG=6,ISV=10K OOBJ=5,RTB=0) /* ——---—-- LONG *} 
PGN=3, (DMN=1,APG=9,ISV=100K ,OOBJ=6,RTB=0) /* HOT BATCH */ 
PGN=4, (DMN=1,APG=6,ISV=10K,OBJ=7,RRB=0) /* LOW PRTY BATCH */ 


Figure 3-8. The Default IPS 


Notes on the default IPS: 


The multiple identical objectives (1,3, 4 and 5) are intended solely as a means to 
provide more detailed RMF workload reports. 


Objective slopes are defined such that address spaces leaving their ISV willhave 
recommendation values of at least 1 less than the cut-off level. 


Jobs associated with performance group 3 will in effect run nonswappable due to 
the characteristics of performance objective 6. 
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IPS Examples 


Example 1 


Assume: 
e A 168 TSO/Batch system with 3 megabytes of real storage. 


@ On the average, 30 users are logged on doing program development work, with 
compiles and test execution. Short commands have top priority. The compiles 
and tests may be deferred. 


@ Batch class X work has a 1-hour turnaround requirement. All other batch work 
is class A and has a 24-hour turnaround requirement. 


e Five initiators are started to class XA. 


CPU=10.0, |OC=8.0, MSO=1.1 /* IPS Example 1 */ 
WKL=(1,25,100) 
OBJ=1,SRV=(2000,*,0) 
OBJ=2,SRV=(1000,*,0) /* Normal Batch m/ 
DMN=1,CNSTR=(1,10,5) /* Batch-like Domain ¥/ 
DMN=2,CNSTR=(3, 12,10) /* Short TSO Domain */ 
DMN=3,CNSTR=(2,2,1) /* Long TSO Domain */ 
DMN=4,CNSTR=(3,3,1) /* Domain For Monitors */ 
PGN=1,(OBJ=2,DMN=1,ISV=20K) /* Batch, except class X */ 
PGN=2, (OBJ=1,DMN=2,DUR=800,ISV=2K ,APG=14) /* TSO — short i 
(OBJ=1,DMN=2,DUR=1200,ISV=2K,APG=13) /* TSO — medium “) 
(OBJ=1,DMN=3,DUR=10K,ISV=10K ,APG=11) /* TSO — long */ 
(OBJ=1,DMN=1,ISV=20K) /* Batch - like TSO */ 
PGN=3, (OBJ=1,DMN=1,ISV=20K ,APG=10) /* Batch class X */ 
PGN=4, (OBJ=1,DMN=4,APG=15) /* Monitor programs sf | 


Notes on Example I: 


The values for the service definition coefficients were determined by starting with 
CPU=10 and then using the definition of the three service components to equalize 
their importance. For example, the value of MSO was calculated by using the 
equation: 


MSO*460*151. 


10* 151 
50 


The value of IOC was determined in the same manner. 


TSO work is favored over batch work via higher dispatching priorities until it 
exceeds 12K service units, after which it is assigned a lower dispatching priority 
than class X batch work. 


Two monitoring programs (for example, RMF and a storage monitor routine) 
are assigned to a unique performance group (PGN4) and domain (DMN4) to obtain 
RMF reports showing the amount of service they use. These programs are assured 
immediate swap-in (minMPL = 3) and in addition are assigned a high dispatching 
priority. 
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2) 


3) 


Decrease the target MPL for the short TSO transaction domain by lowering 
the maximum MPL. This should produce a steady number of swapped out 
TSO transactions, thus providing a more consistent delay for all transactions 
and the elimination of erratic response time. It may, of course, also mean 
an overall increase in response time and a lower transaction rate for all TSO 
transactions. 


Create a staging queue for TSO transactions. In the TSO performance 
group, add a new period, possibly preceding the current first period. 
Associate this period with a domain having a minimum and maximum MPL 
of O, and assign a real time duration of 1 or 2 seconds to the period. This 
provides a real time lag to all commands, thus lowering the transaction rate 
and eliminating the contention that has caused erratic response time. If 
small, this delay may not even be noticed at the terminal. 


Problem 2: TSO Response Time Is Too Fast 


Detection: The objective criteria established when defining installation require- 


ments is the only means of judging this condition. Both SMF 
(records 34 and 35) and RMF provide service usage and transaction 
information. 


Possible Causes: 


a) TSO domains are too heavily favored. 
As TSO address spaces become ready, they are being allowed instant access to 
system resources. This may be slowed in two ways: 


1) 


2) 


3) 


Introduce the delay (staging queue) as described in Problem 1. 


Lower the maximum MPL for the short TSO domain to the average number 
of ready address spaces as indicated by the RMF report. 

This eliminates the slight advantage the domain would have received in the 
instances where the target MPL had previously exceeded the average number 
of ready users. 


Lower the weighting factor of the short TSO domain. Contention indexes 
should be recalculated to ensure the appropriate domain priority scheme. 


b) TSO has too great a dispatching priority advantage. Possibly, long TSO trans- 
actions should use the same range of dispatching priorities as batch work. This 
will help delay long TSO response time, but will not slow down short TSO 
response. However, placing any address spaces at an equal or higher priority 
than short TSO transactions may cause erratic response time, and thus is a 
fairly drastic solution. 
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Problem 3: TSO Response Time is Poor ) 


Detection: Once again, only the criteria established while defining installation 
requirements can identify this problem. SMF (records 34 and 35) and 
RMF provide service usage and transaction information. 


Possible Causes: 


a) The maximum MPL for the short TSO transaction domain is too low, and/or the 
weight is too low. 
If there are always more users ready than the maximum MPL will allow into 
storage, the time each of them spends waiting to be swapped in may be causing 
the long response time. If the RMF trace report indicates a consistent supply of 
ready users in the TSO domain, the maximum MPL, and possibly the weight, 
should be increased to give TSO better response. 


b) The minimum MPL is too small. 
Under fluctuating load conditions, the MPL adjusting function may not be able 
to react quickly enough to high bursts of demand for resources, since it does not 
raise the target MPL to more than 1 above a weighted average of ready users. 
Hence, the target MPL will remain very stable. 
If this target is too low to allow users immediate access to the CPU, response 
time may be impacted. This would probably be perceived as erratic response 
time, as described above, but extreme cases could produce consistently slow 
response time. Raising the minimum MPL constraint to a large value — that is, 
close to the maximum number of ready users — will improve the response time. 


‘ 
c) The dispatching priority scheme may be a problem. J 
If short TSO transactions have a dispatching priority lower than other work, 
response time may be affected. Ensure that at least long TSO transactions are 
placed at a lower priority than short TSO transactions. Refer to the discussion 
under Problem 1. 


d) Long-running TSO commands may be interfering with short TSO response. 
Long TSO commands (especially batch-like work) can be detrimental to short 
TSO response time. Performance group periods should be used to alter domains, 
objectives, or dispatching priorities as a command ages. The duration values of 
each period should be examined to ensure that lengthy commands are not 
monopolizing the TSO domain. 


e) Paging overhead may be impacting TSO response. 
If RMF paging activity reports indicate a high Pageable System Area paging rate 
compared to the address space paging rate, TSO response may be delayed due to 
time spent waiting for pages. Frequently referenced modules have a tendency 
to remain in storage, but moderately referenced routines may be continually 
paged in and out. Examine the PLPA and consider “fixing” these moderately 
referenced routines. 
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Example 2 


Assume: 
e A 168 TSO/batch system with 4 megabytes of real storage. 


e@ On the average, 40 users are logged on doing mainly data entry. Several users 
execute matrix manipulation and graph display jobs from a terminal. 


Batch class C has a 1-hour turnaround requirement. 
Batch class B has a 2-hour turnaround requirement. 


All other batch jobs are class A with 24-hour turnaround. 


Five initiators are started for class C, three for class B, and none for class A until 
TSO is shut down. 


CPU=10.0, |OC=5.0, MSO=0.0 /* IPS Example 2 */ 

WKL=(1,50) 

OBJ=1,SRV=(500,0) 

OBJ=2,SRV=(1000,0) 

OBJ=3,SRV=(2000,2000) /* Batch class A si 

DMN=1,CNSTR=(0,0, 1) /* A delay domain sy 

DMN=2,CNSTR=(4,40,7) /* Short TSO */ 

DMN=3,CNSTR=(1,2,20) /* Long TSO */ 

DMN=4,CNSTR=(3,10,2) /* Batch */ 

PGN=1,(OBJ=1,DMN=4,ISV=5K) /* Started Tasks */ 

PGN=2, (OBJ=1,DMN=1,DUR=2,UNT=R) /* Trivial Delay *} 
(OBJ=1,DMN=2,DUR=400,ISV=400,APG=9) /* TSO — © short */ 
(OBJ=1,DMN=2,DUR=600,ISV=1000,APG=8) /* TSO — medium */ 
(OBJ=1,DMN=3,ISV=2K) /* TSO — long */ 

PGN=3,(OBJ=2,DMN=4,ISV=10K) /* Batch class C #/ 

PGN=4,(OBJ=1,DMN=4,ISV=10K,DUR=3600,UNT=R) /* Batch class B */ 
(OBJ=2,DMN=4,ISV=10K) 

PGN=5, (OBJ=3,DMN=4,ISV=100K) /* Batch class A */ 


Notes on Example 2: 


MaxMPL for the short TSO domain (DMN72) is equal to the average number of 
logged on users. 


MaxMPL for the batch domain (DMN4) is equal to the maximum number of 
started initiators (5+3+2). 


After calculating contention index values, domain weights were assigned to allow 
long TSO work (DMN3) the greatest chance of having its target MPL raised. 


Access to resources is delayed by 2 seconds for all TSO commands (DMN1). This 
method helps prevent erratic response by providing a more constant TSO load 
(that is, a constant arrival rate of TSO work). 


Each batch initiator class is associated with a unique performance group. The 
default performance group (PGN1) is used only by started tasks. 


If a class B job has not completed in one hour, it is given a special boost to enable 
it to complete in the remaining hour of its turnaround requirement (see PGN4). 


Class A batch is run only at night, with no particular turnaround requirements. 
Jobs can execute to completion without swapping since no workload control is 
necessary. Therefore, a large ISV is used. 
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Evaluating and Adjusting the IPS and OPT ) 
This section is intended as an aid in interpreting measurement data and adjusting 
the IEAIPSxx and IEAOPTxx parameter values. 


The first part of this section addresses possible causes for a failure to meet fixed 
response and throughput requirements. The analysis relies on MF/1 or RMF 
reports, and other measurement data as established by the installation when 
defining the fixed requirements. 


The second part addresses the optimal use of the SRM control mechanisms, that 
is, how to achieve fixed requirements with a minimum of swapping and paging 
overhead, and how to maximize throughput via job mix control. 


Note that the controls offered by the SRM are only one aspect of the tuning 
process. Therefore, adjustment of IPS and/or OPT parameters may not be effective 
if basic system tuning is needed. 


Fixed Requirements Are Not Being Met 
Problem 1: Short TSO Response Time is Erratic. 


Detection: User feedback or personal experience while using TSO will be the best 
detection method. MF/1 and RMF report only average response times. 


Possible Causes: 


a) The dispatching queue is not ordered properly. 
If short TSO transactions are placed on the dispatching queue behind relatively 
long transactions, long response times can occur. Use the APG feature in the IPS 
to place long TSO transactions at a lower dispatching priority than first period 
TSO transactions, and ensure that the long transactions are indeed switching to a 
new period (DUR value for short TSO transactions is not too large). 


Also, examine the use of dispatching priorities higher than or equal to the short 
TSO transaction priority. There may be dispatching queue interference from 
memory create processing and from the initiator priority as specified in 
“SYS1.PROCLIB(INIT)”’. 


b) The number of TSO users waiting to be swapped in is not uniform. 
Sporadic waiting periods translate into user-perceived erratic response time. 
RMF tracing reports will indicate the number of users swapped out for the 
short TSO transaction domain. If this value fluctuates, there are several possible 
solutions: 


1) Increase the target MPL for the short TSO transaction domain by raising the 
minimum MPL above the observed average number of ready address spaces. 
The minimum MPL may need to be increased several times, even to the 
mean observed maximum number of ready address spaces. This will help 
ensure that when a TSO address space becomes ready, it will be swapped in. 
This will provide consistent short TSO transaction response, but may also 
mean that short TSO transactions will consume more system resources than J 
is tolerable, introducing, for example, sudden heavy page demands. 
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Problem 4: IMS Response Time or Transaction Rate Is Too Good. 


Detection: The IMS statistical program, or any other method decided upon when 
specifying installation requirements, will indicate whether this is a 
problem. 


Possible Causes: 


Dispatching priority is too high. 

Whether IMS is swappable or non-swappable, if its dispatching priority is placed in 
the APG range and controlled by the SRM, other work may be placed above or 
equal to the IMS priority, thus causing IMS to slow down. 


Problem 5: Batch Turnaround Time Is Not Good Enough. 


Detection: SMF type 5 records provide elapsed time information for all jobs. 
MF/1 and RMF provide average elapsed times. The installation will 
have specified the criteria for elapsed times when establishing fixed 
requirements. 


Possible Causes: 


a) Job classing may be ineffective. 
If tape merges, file sorts, or other long jobs are run in a job class with jobs that 
have fast turnaround requirements, they could monopolize the initiators while 
short jobs wait on the queue for selection. SMF type 5 records provide 
sufficient information to determine whether jobs are indeed waiting a long time 
to be initiated. Ensure that jobs are placed in the proper initiator class. 


b) TSO or IMS may be using more of the system than planned. 
If this is true, batch work will have less resources available. Either reinvestigate 
fixed requirements, or refer to appropriate problems listed in this section. If 
resources are available and the batch domain is consistently at its maximum 
MPL, raise the maximum. 


c) Swapping may be slowing down throughput. 
The initial ISV for the batch performance group should be large enough to 
allow the majority of short jobs to complete without a swap. This is an unlikely 
cause of this problem since swapping is a control that executes in a range of 
seconds, while throughput is measured in minutes or hours. However, if an 
excess of initiators are started, there may be inordinate waiting times when 
swapped out. 


d) Jobs that don’t have a fast turnaround requirement may be interfering with 
jobs that do. 
Within the batch domain, use objectives to distinguish between the performance 
needs of various types of work. The properties of slopes, ISVs, and cut-off 
points can help ensure that turnaround requirements are met. 
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Optimizing the Use of Control Mechanisms 


Problem 6: Swapping May Be Causing Excessive Overhead. 


Detection: The RMF paging activity report lists total swap out counts. These 
counts will indicate the causes contributing to swapping overhead. 
Some of these can be attributed to the SRM, some to applications. 
Since swapping is a costly control mechanism, the number of 
unnecessary swaps should be kept at a minimum. 


Possible Causes: 


a) “Input terminal wait’ swap count is high. 
In a TSO environment, the vast majority of swaps should be of this type. 
This is not a problem. 


b) ‘Output terminal wait” swap count is above 0. 


1. TSO commands or CLISTs may produce output so fast that the TIOC does 
not have sufficient buffers available or sufficient buffers may not have been 
allocated initially. This causes the address space to be automatically 
swapped out of storage until the output buffers have been emptied. The 
SRM treats this condition as the end of a transaction. If the excess swaps 
are counted here, the problem may be eliminated by increasing the 
OWAITHI value in the IKJPRMxx PARMLIB member. 


2. Another application-induced practice that may cause an output wait swap 
is the issuance of a TPUT SVC with the ‘HOLD’ keyword. 


c) “Long wait” swap count is high. 
Applications that expect to wait for long periods of time (WAIT macro with the 
LONG option, STIMER for greater than 0.5 seconds) will be swapped out. 
Investigate the possibility of rewriting such applications. 


d) “Detected wait” swap count is large. 
These swap outs occur when an address space in storage has been non- 
dispatchable for a fixed period of time as, for instance, when an initiator 
finishes with a job and then finds no other available jobs on the queue. If this 
count is larger than the number of swaps that can be attributed to idle initiators, 
investigate which jobs are waiting and correct the responsible program(s). 


e) “Unilateral” swap count is high. 
In a batch environment, this count may equal the number of ended batch jobs. 
If the count is higher than this, the extra swaps may have been caused by the 
staging of work through several domains with improper minimum MPL values. 


For example, if medium TSO transactions are switched from a domain with 

a high target MPL into a domain with minMPL = maxMPL = 1, only one medium 
transaction will be allowed in storage at a time. The others will be swapped out 
because the target MPL is exceeded, that is, unilateral swap outs will occur. 
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The RMF workload activity report indicates, by performance group period, the 
ratio of swaps to ended transactions. This can assist in finding the period 
causing extra swapping. 


Note, however, that the technique of delay for TSO as described under Problem 
1 will not induce unilateral swaps because the delay is incurred in the first 
period, before the TSO address space is swapped into storage. 


f) “Exchange on recommendation value” swap count is high. 
These control swaps are dictated by the IPS and may be excessive for several 
reasons. 


1) 


2) 


An ISV value is too small. 

Remember that the ISV is the primary determinant of swapping frequency. 
It should be large enough to accommodate transactions with such severe 
response time requirements that swapping is an inappropriate control. RMF 
workload reports that summarize by domain and period will help locate 

the area causing the extra swapping. 


Different cut-off workload levels exist in a domain. 

The use of different cut-off workload levels is a valid workload management 
technique. It provides a simple priority scheme within a domain. However, 
address spaces associated with the objective having the higher cut-off point 
may be constantly preempting address spaces on other objectives, even in 
their ISV. If this preemption is frequent, there may be a problem in 
domain definition. 


For example: 


1500 
OBJ 1 


OBJ 2 


1 80 100 


In a batch domain, a ‘hot’ job on objective 1 will preempt normal jobs on 
objective 2, and cause an exchange swap. If an installation has many hot 
jobs, however, they may be candidates for a domain of their own to prevent 
interference with normal batch work. 
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Another solution would be to use the same cut-off workload levels, but 
utilize objective slopes to indicate job priority. Now the hot job on 
objective 1 will not preempt normal batch until the latter leaves its ISV, 
after which the hot job will be swapped in and execute to completion. 


1500 


OBJ 1 


1 79 80 


g) “ENQ Exchange” swap out count is not close to zero. High contention for 
serial resources is causing extra swapping. 
Even if this count is low, there may still be an entqueue bottleneck if the 
“unilateral swap count” in a batch environment is much higher than the number 
of ended batch transactions. This is possible because the SRM will exceed the 
target MPL, if necessary, to ensure that a resource holder is swapped in for its 
ERV time. Investigate enqueue contention in the system. 


Problem 7: Paging Overhead Is High. 


Detection: The RMF paging activity report shows the total system non-swap 
page-in and page-out values. If the sum of these values indicates that 
significantly more than 5% of CPU time is used for paging, the installa- 
tion is probably incurring excessive overhead. Five percent is a rate 
of approximately 15 pages per second for a 158 UP and approximately 
30 pages per second for a 168 UP. 

In addition to this report, RMF traces the highest system UIC and the 
count of available frames. A UIC value that is consistently 0 could 
indicate an overcommitment of storage, since this means that no pages 
are allowed to go unreferenced for 1 second. This condition defeats 
the SRM’s storage management algorithm, that is, no distinction 
between the age of frames is possible. 


Possible Causes: 


a) Overcommitment of real storage, probably due to large minimum MPL values. 
The SRM will adjust each domain’s target MPL based on system contention 
indicators and the constraint values. If the paging rate indicates the need to 
decrease the total MPL, but all target MPLs are currently at the minimum MPL 
values, the SRM cannot respond. The installation should either increase the 
amount of real storage, or decrease the minimum MPL value for at least one 
domain. 
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b) Examine the use of the link pack area (LPA). 
Investigate the feasibility of packing and repackaging to obtain more efficient 
use of storage. 


Problem 8: Resources are Unused. 


Detection: RMF reports indicate system resource usage. If these show a high CPU 
wait time, little paging, or low channel activity, the system may not 
be fully utilized. 


Possible Causes: 


a) The maximum MPL for domains is too low. 
If all domains have a target MPL equal to the maximum value, the SRM is 
unable to increase system utilization by raising the target MPL of a domain. 
Therefore, resources will be underutilized. Increasing the maximum MPL of at 
least one domain that consistently has ready work waiting should alleviate this. 


b) Some resource is a bottleneck. 
If RMF indicates several underutilized resources, but shows one to be con- 
sistently overutilized, increasing the MPL of a domain will probably not help. 
Instead, the service definition coefficients may be altered by raising the 
coefficient of the overutilized resource. This will have the effect of increasing 
the service rate for users of that resource, thus producing a lower workload level 
and causing earlier swap outs. 
Note: Changing the service definition coefficients may require changing other 
service dependent parameters in the IPS (ISV, DUR and OBJ). Also, RMF and 
SMF transaction and service statistics will differ from previous reports. 
If the overutilized resource can be associated with a specific performance group 
or period, the RTB for that period or performance group may be set to 1 to 
allow the load adjusting functions to eliminate the bottleneck. In conjunction 
with these changes, the resource factor coefficient of the overutilized resource 
may need to be raised to give more weight to the load adjusting swap 
recommendations. 


Section 4: Installation Management Controls 


This section contains information about JCL statements and operator commands 
for SRM-related installation management functions. 


Assigning Performance Group Numbers 


The PERFORM parameter on the JOB or EXEC JCL statement is used to associate 
a performance group with a job or job step (see the publication OS/VS2 JCL, 
GC28-0692). 


The PERFORM parameter value on the JOB statement associates all steps of a 
job with a performance group. If no PERFORM parameter appears on the JOB 
statement, the parameter value on the EXEC statement will be used for the 
associated job step. 
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If an invalid performance group is specified, a warning message indicating non- 
verification and default substitution will be issued, The default for non-TSO jobs is J 
1; for TSO jobs it is 2. 

If PERFORM is specified for a procedure, the specified value is effective for the 
entire procedure. If PERFORM.procstepname is coded for a procedure, the value 
is effective only for the procedure step named. 


If no PERFORM parameter is specified on either the JOB or EXEC statements, 
a default will be assigned. If JES2 is the primary I/O subsystem, the default values 
may be specified by the installation in the JES2 initialization parameters. (See the 
parameters &STC, &TSO, &X in the publication OS/VS2 SPL: JES2, GC23-0001. 
Defaults may be assigned for started tasks, time sharing users or any batch class.) 


If a performance group is not specified via the PERFORM parameter and is not 
assigned by JES2, the IBM-supplied default will be assigned. 


For TSO users, the PERFORM parameter may also be specified on the LOGON 
command. (See the publication OS/VS2 TSO Command Language Reference, 
GC28-0646). If the user requests a performance group not specified in the UADS, 
the IBM-supplied default of 2 is assigned. 


Assigning Dispatching Priorities 


The DPRTY parameter, which may be included on the EXEC JCL statement, is 

used to assign a dispatching priority to a job step. (See the publication OS/VS2 
JCL, GC28-0692.) Job steps that do not include the DPRTY parameter on their J 
EXEC statements are automatically assigned an APG priority. 


If the job step is assigned an APG priority, the specific priority value is obtained 
from the IPS specification. If no value is specified in the IPS for the corresponding 
period, the default is 6 (mean-time-to-wait). 


Operator Commands Related to the SRM 


The system operator can directly influence the SRM’s control of specific jobs or 
groups of jobs by entering commands from the console. The exact format of these 
commands is defined in the publication Operator’s Library: OS/VS2 MVS System 
Commands, GC38-0229. 


The RESET command is used to change the performance group of an 
executing job. 


The SETDMN command provides a way for altering the constraint values on a 
domain’s multiprogramming level. The information from this command is valid 
only for the life of the IPL — it does not change fields in the IPS member. 


The SET command with the IPS parameter is used to switch to a different IPS 


after an IPL. The SRM will base all control decisions for existing and future jobs 
on the parameters in the new IPS. 


202.16 OS/VS2 System Programming Library: Initialization and Tuning Guide (VS2.03.807) 


VS2.03.807 


Section 5: 


To understand whether the system is running effectively with the current IPS, 
an installation needs dynamic system status information. The DISPLAY command 
with the DOMAIN keyword provides a snapshot of an individual domain’s status. 


SRM Parameters 


This section describes the syntax rules, keywords, and the value ranges and defaults 
for the parameters specified in the SYS1.PARMLIB members IEAIPSxx and 
IEAOPTxx. 


Syntax Rules 


Keywords, appearing in upper case letters, must be written exactly as indicated. No 
imbedded blanks are permitted in the keywords, and the keywords may not span 
logical records. Information is written on 80 byte logical records. The data may 
extend from byte 1 through byte 71; the contents of bytes 72 through 80 will be 
ignored. 


Any number of blanks may follow a keyword. All required keywords must be 
specified in the sequence shown, except where noted, and must be separated by a 
delimiter. A delimiter, shown in the syntax descriptions as a comma, can be a 
comma followed by one or more blanks, or it can be any non-zero number of 
blanks. 


Comments are permitted whenever blanks are allowed. The general format of 
a comment is: 


/*character string*/ 
The slash and asterisk must be immediately adjacent. The character string may 
contain any characters except the */ combination. 
IEAIPSxx Parameters 


The IPS contains five categories of information. They must be specified in the 
order shown. 
1. Service definition coefficients: 

[CPU=xx.x] [IOC=xx.x] [MSO=xx.x] 


(Note: these keywords can be specified in any order.) 


2. Workload levels: 
WKL=(xxx,xxx[,...]) 


3. Performance objectives: 
OBJ=xx, SRV=(xxxx[,.. .]) 


The maximum number of performance objectives that can be specified per IPS 
is 64. 
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4. Domains: 
DMN=xxx, CNSTR=(xxx,xxxX,XXX) 


The maximum number of domains that can be specified per IPS is 128. 


5. Performance groups: 
PGN=xx, (DMN=xx,OBJ=xx,DUR=xxxxxxxxx 


ont st [ ISV=xxxxxx] [,RTB=x] 
[,APG=xx] ) 


R 
(C- )] 


The keywords within a set of parentheses represent a performance group 
period. 





The maximum number of performance group periods that can be specified 
per performance group is 8. The maximum number of performance groups 
that can be specified per IPS is 255. (Note: The keywords comprising a 
performance group period can be specified in any order.) 
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Keyword 


APG 


CNSTR 


CPU 


DMN 
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Parameter Descriptions 


Meaning 


Specifies the dispatching priority within the APG range that will 
be assigned to a transaction. 
The APG is divided into three distinct groups: 


Mean-time-to-wait 0-6 
Rotate 11 
Fixed 7-10, 12-15 


Example: APG=12 


The resultant dispatching priority, assuming the default APG 
range, is 7C. 


Specifies the constraints of a domain, that is, the minimum MPL, 
the maximum MPL, and the weighting factor, respectively. 

All three constraint values must be specified. The value ranges 
for the constraints are: 


minimum MPL 
maximum MPL 
weighting factor 


Example: DMN=2,CNSTR=(7,10,15). This indicates, for 
domain number 2, a minimum MPL of 7, amaximum MPL of 10, 
and a weighting factor of 15. 


Indicates the number by which accumulated CPU service units will 
be multiplied (weighted). 


Example: CPU=1.0 


Specifies a unique number that is used to associate a domain 
with a transaction. 


Example: DMN=5 

Note: 

If domain 1 is not specified in the IPS, it will be defined 
automatically with constraints of (1,255,1). 

If no domains are defined in the IPS, the domain for each 


performance group period will default to 1, with constraints of 
(1,255,1). 


If a domain is specified in the IPS, the first period of a performance 


group must contain a domain specification. 


If no domain is specified in subsequent periods, the last previously 
specified domain number will be assigned. 


Value Range 


0-15 


0-255 
0-255 
1-255 


0.0 - 99.9 


1-128 


Default Value 


6 


none 
none 
none 


1.0 


(see Note) 
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Keyword 


DUR 


lOC 


ISV 


MSO 


OBJ 


PGN 


RTB 


SRV 
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Specifies the length of the performance group period in units 
indicated by the UNT keyword, 


Example: DUR=400 


Every performance group period must have the DUR parameter 
specified except for the last performance group period ina 
performance group. 


*If UNT=R is specified for a performance group period and a DUR 
value greater than 1,000,000 is assigned, 1,000,000 is used in place 
of the assigned value. 


Indicates the number by which accumulated I/O service units will 
be multiplied (weighted). 


Example: \OC=1.0 


The interval service value specifies the minimum number of service 
units that a transaction should receive during each interval of real 
storage Occupancy. 


Example: \SV=800 


Indicates the number by which accumulated storage service units 
will be multiplied (weighted). 


Example: MSO=1.0 


Specifies a unique number that associates the performance 
objective with a particular period in the processing of a transaction. 


Example: OBJ=8,SRV=(200,100,0) 


Specifies a unique identifier for a performance group definition. 
This number is used to associate a job, job step or time-sharing 
session with the respective performance group. 


Example: PGN=3 


Note: 
Each IEAIPSxx member must have performance groups 1 and 2 
specified. 


Specifies the response/throughput bias for a particular performance 
group period. 

A value of ‘’1” indicates that the CPU and I/O load adjusting 
recommendations are to be added to the workload recommendation 
during swap analysis. A value of ’’0” indicates that the CPU and 
1/O load adjusting recommendations are to be ignored. 


Specifies the service rates that define performance objectives. 
The number of service rates may be equal to or less than the 
number of workload level values. 


Example: OBJ=3,SRV=(1000,500,0) 


Value Range 


0-999999999 
or 0-999999 K * 


0.0 - 99.9 


100 - 999999 
or 100 - 999K 


0.0 - 99.9 


1-64 


1-255 


0-1 


0-9999 


Default Value 


none 


none 


100 


1.0 


none 


none 


none 


C 


Notes: 
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1. If more service rates than workload level numbers are specified, the extra service rates are 


ignored. 


2. An asterisk (“) can appear in place of a numerical SRV value. When it appears between 
two numerical values (for example SRV=(100,",0)), it indicates that a linear graph 
connects the point before the asterisk with the point after the asterisk. Thus, with 
workload levels WKL=(10,20,30), SRV=(100,*,0) is equivalent to SRV=(100,50,0). 

If no number follows the asterisk, the line joining the previous two values is extended. 
Thus, with WKL=(10,20,30), SRV=(100,75,") is equivalent to SRV=(100,75,50). If 
only one value precedes the asterisk, and no values follow the asterisk, the single value 

is repeated. Thus, with WKL=(10,20,30), SRV=(100,*) is equivalent to SRV=(100,100). 


Keyword 


UNT 


WKL 


Meaning 


Value Range Default Value 


Specifies the units for the DUR parameter. ‘‘S” indicates service S,R S 


units; ‘’R”’ indicates real time in seconds. In the following exa 


mple, 


the period duration for objective 6 is 4 seconds; for objective 7, 


4000 service units. 


PGN=2, (DMN=1,OBJ=6,DU R=4,UNT=R) 
(DMN=1,QBJ=7,DU R=4000) 
Vac) 


Specifies a series of positive numbers of increasing value. They 
provide a reference for defining performance objectives. There 
can be up to 32 numbers in any workload level specification. 
The following example illustrates a workload specification and 
two related performance objectives. 


WKL=(1,50,99,100) 
OBJ=3,SRV=(400,300,"*,0) 
OBJ=4,SRV=(400,300,0) 


1-128 none 
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Keyword 


CPU 


lOC 


ERV 


Note: 
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IEAOPTxx Parameters 


The OPT contains two categories of information: 


1. Resource factor coefficients: 


[RFC [CPU=x.x] [ JOC=x.x] ] 


2. Resource manager constant: 


[RMC ERV=xxxxxx] 


(Note: refer to the syntax rules described at the beginning of this section.) 


Parameter Descriptions 


Meaning 


Specifies the weighting factor by which the recommendation of the 
CPU load adjusting function is to be multiplied, when an address 
space is evaluated for swapping. 


Example: CPU=3.0 


Specifies the weighting factor by which the recommendation of the 
[/O load adjusting function is to be multiplied, when an address 
space is evaluated for swapping. 


Example: \OC=2.0 


Specifies the ‘“enqueue residence value’’. This is a multiplication 
factor used to calculate the amount of task execution time during 
which an address space should not be swapped out, if the address 
space is enqueued on a system resource needed by another address 
space. 


Example: ERV=2 


Value Range 


0.0 - 9.9 


0.0 - 9.9 


0-999999 


The SRM determines the execution time by multiplying the ERV by the model-dependent 
time needed to accumulate 1 CPU service unit. 


In the example given, if an address space can consume 1 service unit in 10 milliseconds, 


it will be allowed to execute for 20 milliseconds, when it is enqueued on a resource 


requested by other address spaces, before it will be eligible for swap-out. 
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Section 6: SRM Constants 


This section lists internal SRM constants which an installation with unique 
resource management requirements may want to change. Before making such a 
change, it will, in most cases, be advisable to study related segments of code in 
order to be able to predict the impact of the contemplated change on internal SRM 
algorithms and, therefore, on SRM evaluations and decisions. 


In the table of constants, internal control blocks are denoted by their acronyms, 


as follows: 

RCT = — Resources Control Table 

RMPT — Resources Manager Parameter Table 
MCT — Storage Management Control Table 
ICT — I/O Control Table 

PVT — Page Vector Table 

CCT = — CPU Management Control Table 















RecuictL | RCT | _MPL adjustment UIC low threshold ra 
RCCUICTH MPL adjustment UIC high threshold eee, 


RCCCPUTL MPL adjustment CPU utilization low threshold 96% (times a scaling 
factor of 16) 

RCCCPUTH MPL adjustment CPU utilization high threshold 100% (times a 
scaling factor of 16) 


RCT 

RCT 

RCT 

RCT j 
RCCPTRTL RCT MPL adjustment Paging rate low threshold 100 pages/second 
RCCPTRTH RCT MPL adjustment Paging rate high threshold 100 pages/second 
RCCASMTL MPL adjustment ASM queue length low threshold ie te 
RCCASMTH MPL adjustment ASM queue length high threshold ADT dl 


RCCTOTUT MPL adjustment Average total logical channel utilization 0% 
threshold 


7 
2 
RCCLCHUT MPL adjustment Single logical channel utilization threshold 30% 


RCCLCHRR MPL adjustment Single logical channel EXCP request rate 50 EXCPs/second 
threshold 


RMPTTOM RMPT Minimum SRM invocation interval 500 milliseconds 


RMPT XCHT RMPT Swap analysis Exchange swap threshold 1 (times a scaling 
factor of 256) 


RMPTSAET RMPT Swap evaluation threshold 1000 milliseconds 


MCCPLUS Page stealing Available frame queue delta for stealing iL 40 — = 
MCCINTMX Page stealing Maximum UIC updating interval 2000 milliseconds 
| 


MCCUICBD Page stealing Maximum system UIC before UIC updating 
interval changes 
MCCASMT 1 MCT Auxiliary storage Auxiliary storage shortage threshold 70% 
shortage detection 
MCCASMT2 MCT Auxiliary storage Critical auxiliary storage shortage threshold 85% 
shortage detection 
ICCMNSWP ICT 1/O load adjusting Minimum swap out time for I/O imbalance 30000 milliseconds 
correction 
i i 













ICCMNIOR 1/O load adjusting Minimum I/O rate for user 1/O monitoring 5 EXCPs/second 


PVTPERFX Pageable storage Maximum fixed frame threshold - 80% 
shortage detection 
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| PVT Pageable storage Acceptable fixed frame threshold 60% 
| shortage detection 

| ICT Device allocation Projected impact on logical channel 
: utilization of a previously allocated data set 


| 
| ICCINHI1 ICT 1/O load adjusting Percentage of delayed 1/O requests above 
| which a logical channel is considered to be 
_ 


Constant 


PVTPEROK 
















70% 








overutilized for a uniprocessor system 






1/O load adjusting Percentage of delayed |/O requests above 80% 
which a logical channel is considered to be 


overutilized for a multiprocessor system 


















ICCINLO1 ICT 1/O load adjusting Percentage of delayed |/O requests below 30% 
which a logical channel is considered to be 
underutilized for a uniprocessor system 

ICCINLO2 ICT 1/0 load adjusting Percentage of delayed |/O requests below 40% 


which a logical channel is considered to be 
underutilized for a muitiprocessor system 


ICCSIGUP 


1/O load adjusting Percentage of I/O requests to a logical channel | 5% 
that determines a heavy user of that channel 

1/O load adjusting Minimum elapsed time before a logical 2000 milliseconds 
channel utilization computation will take place 

1/O load adjusting Minimum elapsed time before a user I/O 10000 milliseconds 
rate computation wiil take place 


1/O load adjusting 


ICCMNLIN 


ICCMNUIN 






ICT 
ICT 
ICT 

CT 





ICCMXICT I Maximum elapsed time a heavy |/O user 60000 milliseconds 
may remain in real storage without having 


its |/O usage monitored 


CCCUTHIT CCT CPU load adjusting Percentage of time a CPU was not in the wait 
state, above which the CPU will be considered 
overutilized 


CCCUTLOT CCT CPU load adjusting Percentage of time a CPU was not in the wait 
state, below which the CPU will be considered 
underutilized 


CCCSIGUR CCT CPU joad adjusting Minimum mean-time-to-wait to be considered 28 milliseconds 
a heavy CPU user 
CCCAPDIV CCT APG Range.of a subgroup within the mean-time-to- | 4 milliseconds 
wait group (value given is for Model 155 
Mod 11) 
CCCAPRHT CCT APG Percentage of APG users whose priority must 60% 
change at an invocation of this function, 
— 
CCT APG 


before the invocation interval is shortened 
CCCAPRLT 









100% 


80% 




















Minimum user execution time before a new 200 milliseconds 
dispatching priority will be computed for 


the user 









Percentage of APG users whose priority must 
change at an invocation of this function, 
before the invocation interval is lengthened 


CCCAPROT Cc APG Rotate dispatching priority in APG 


CCCAPGDP CCT APG Default mean-time-to-wait dispatching 
priority in APG 


: 
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- Part 4: How to Use the System Activity Measurement Facility (MF/1) 


The System Activity Measurement Facility (MF/1) is an analysis tool which an 
installation may use to monitor selected areas of system activity, and obtain feed- 
back in the form of SMF records and/or formatted reports. MF/1 permits the 
gathering of information on the following classes of system activity, either 
individually or in combination: 


e CPU activity 
e@ Channel activity and channel-CPU overlap activity 


e I/O device activity and contention for: 
— Unit record devices 
— Graphics devices 
— Direct access storage devices 
— Communication equipment 
— Magnetic tape devices 
— Character reader devices 


@ Paging activity 
e Workload activity 


YY With MF/1, an installation can monitor the utilization of individual CPU’s, 
channels and devices, in order to identify system components whose overall 
utilization is exceptional. The installation can further identify periods of system 
activity during which the utilization of particular resources are exceptional. Finally, 
the installation can relate the service being provided to different classes of users to 
the specifications provided in the Installation Performance Specification (IPS). 


MF/1 is a software monitoring tool. Thus it is limited to reporting on system 
activity as that activity is communicated to the system (for example, by the setting 
of flags). As a result of this indirect reporting, MF/1’s statistically sampled values 
can approach in accuracy only the internal system indications, not necessarily the 
external system activity itself. For example, if a CPU is disabled so that the freeing 
of a device (device end interruption) cannot be communicated to the system, the 
device will appear busy for a longer period of time than it would if it were measured 
by a hardware measuring instrument. 





In an installation using the Mass Storage System (MSS), Mass Storage System 
Trace Report programs are used to monitor the MSS. These programs are described 
in OS/VS Mass Storage System (MSS) Services for Space Management. 


MF/1 Operation 


MF/1 is always generated with the system, but its operation is completely optional. 
The system operator initiates MF/1 monitoring with the START command. MF/1 
can also be started as a batch job. When MF/1 is not operating, it will cause little 
SS performance or storage overhead. When it is operating, the storage and performance 
overhead will depend on the set of options which were specified by the operator. 
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The operation of MF/1 is controlled by a set of parameters that may be 
contained in: 


@ The “‘parmvalue” field of the START command that is issued to start MF/1 
processing. 

e The PARM field of the EXEC statement in the MF/1 cataloged procedure, if 
used (the IBM-supplied procedure does not use it). 

e The MF/1 partitioned data set member (typically a SYS1.PARMLIB member). 


If a parameter is not specified in any of these sources, a program default value is 
used. 


The MF/1 cataloged procedure is named MF1, and resides in the SYS1 .PROCLIB 
data set. The IBM-supplied procedure is: 


/NEFPROC EXEC PGM=|IRBMFMFC,DPRT Y=(15,15) 
//NEFRDER DD DSN=SYS1.PARMLIB,DISP=SHR 
//SYSUDUMP DD SYSOUT=A 


The IEFRDER DD statement names the MF/1 library partitioned data set which 
may contain any number of members, each containing card-image MF/1 control 
input. The member names must be in the form IRBMF Inn, where nn is a decimal 
digit field. The default value for nn, “OO”, may be changed by the MEMBER 
parameter, as indicated below in the explanation of the MEMBER parameter. 


The START and STOP commands used to initiate and terminate MF/1 operation 
have the following syntax: 


START MF1 [.identifier] [,devicename] [,volumeserial] [,parmvalue] 
[,keyword=option,. . .] 


Note: The identifier, although optional during the starting of MF/1, 
must have been specified at START in order to STOP MF/1 from the 
operator’s console. 


STOP [MF1.] identifier (The STOP command will not take effect until 
after the “MF/1 ACTIVE” message has been 
received by the operator.) 


The “‘parmvalue” field may be unused (if MF/1 control parameters are to be 
obtained from a lower priority source), or may contain one or more MF/1 options, 
to be used to control MF/1 for the duration of its execution. If non-alphameric 
characters are used in this field (for example, when more than one option is speci- 
fied, and commas are therefore used as separators), the ‘‘parmvalue” field must be 
enclosed in parentheses. 


The “‘devicename” and “volumeserial” fields are used only when the operator 
desires to override the specifications of the IEFRDER DD statement in the MF/1 
cataloged procedure. When these fields are left blank (as will normally be the case), 
commas must be inserted to indicate their absence if MF/1 parameters are to be 
specified in the “‘parmvalue”’ field. 
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The “‘keyword=option”’ field may be used to specify any special keyword syntax 
desired for the IEFRDER DD statement, or any symbolic parameter keyword 
defined when a user-written cataloged procedure replaces the IBM-supplied one. 
Normally, this field will not be used. 


An example of a typical operator request for MF/1 activity, specifying three 
MF/1 control parameters, is: 


START MF1.EXAMPLE,,,(WKLD(SYSTEM), CYCLE(100), 
DEVICE(NOCOMM)) 


An example of starting MF/1 as a batch job is: 


//MF1 JOB (accounting information) 
/[MF1 EXEC MF1 


MF/1 Options 


For a more detailed explanation of parameter selection and syntax rules, refer to 
the IRBMFxx member description in Part 2: System Initialization. 


The MF/1 control options are summarized below. The underlined values are the 
program default values, and appear in the IBM-supplied SYS1.PARMLIB member 
IRBMF 100. The values of these options to control an MF/1 execution are taken 
from the input sources in the following priority order: 


1. START command “parmvalue”’ field 
2. EXEC statement PARM field 
3. MF/1 partitioned data set member 


An option explicitly specified in the START command will take priority over any 
conflicting specifications of that parameter in the EXEC statement, or the MF/1 
partitioned data set member. An option explicitly specified in the EXEC statement 
will take priority over a conflicting specification in the MF/1 partitioned data set 
member. If there are parameters for which no values are specified in the 
START command, the EXEC statement, or the MF/1 partitioned data set member, 
a program default value will be used. 


OPTION FUNCTION 
CPU Specifies whether or not system CPU activity is to be 
NOCPU monitored by MF/1. 
CHAN Specifies whether or not system channel activity is to be 
NOCHAN monitored by MF/1. 
DEVICE (device list) Specifies whether or not system device activity is to be 
NODEVICE monitored by MF/1. If DEVICE is specified, a device list 


must indicate the classes of devices that will be monitored. 
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OPTION FUNCTION 
Device list choices: J 


CHRDR 
h 
{ NOCHRDR \ Character reader devices 








Communications equipment 


——— Direct access storage devices 





4 cae } ease Gavicss 


NOGRAPH 
TAPE : . 
NOTAPE } Magnetic tape devices 
UNITR : : 
NOUNITR } Unit record devices 
PAGING Specifies whether or not system paging activity is to be 
NOPAGING monitored by MF/1. 
(PERIOD) Specifies whether or not system workload activity is to be 
WKLD (GROUP) monitored by MF/1.If WKLD is specified, the level of detail 
(SYSTEM) of the report to be produced must be indicated by the option 
in the parenthesis. PERIOD requests the most detailed 
NOWKLD workload activity reporting, GROUP requests an intermediate 
level of detail, and SYSTEM requests the least 
detail. } 
CYCLE (value) Specifies the frequency at which sampling observations are 


made of channel and device data. The range is from 50 to 
999 milliseconds. The default is 250 milliseconds. 


value 
INTERVAL { lue M \ Specifies the interval at which all data will be gathered for 
eae report formatting and/or SMF record writing. The range is 
from 1 to 60 minutes. The default is 15M. 


MEMBER (nn) The value specified by this parameter is appended to IRBMF1 
to form the name of the partitioned data set member that 
contains the MF/1 options. The default is 00, indicating 
member IRBMF100 in the partitioned data set named on the 
!EFRDER DD statement in the MF/1 cataloged procedure 
(normally SYS1.PARMLIB). This parameter may be specified 
in the PARM field of the START command or EXEC state- 
ment, but should not be specified within a partitioned data 





set member. 
OPTIONS or OPTN Specifies whether or not a list of the keyword options to be 
NOOPTIONS or NOOPTN {used will be printed at the operator's console at MF/1 


initialization. If the list is printed (OPTIONS or OPTN 
specified), the operator will be able to respond with any 
desired changes to the option list. 


Note: If you don’t plan to specify any options at MF/1 start 
time, you can avoid unnecessary console output and delay in 
activating MF/1 by specifying NOOPTIONS in the MF/1 
partioned data set member. If any syntax errors are detected 
by MF/1, OPTIONS is forced. 


RECORD Specifies whether or not monitored data is to be written to } 
NORECORD the SMF data set. If SMF records are to be written, SMF data 


recording must have been specified during system 
initialization (MAN=ALL). 
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OPTION FUNCTION 


REPORT REALTIME Specifies whether or not printed reports of the monitored 
DEFER data are to be produced. If the reports are to be produced 
(REPORT specified), the REALTIME/DEFER options 
NOREPORT specify whether the reports are to be printed when 
formatted, at the conclusion of a data gathering interval 
(REALTIME specified), or printed after MF/1 processing 
terminates (DEFER specified). 


STOP value Specifies the desired time duration for MF/1 activity, 
value M in minutes or hours. The range is from one minute to one 
value H week (168 hours or 10,080 minutes). The operator STOP 

command will terminate execution at any time, regardless 

NOSTOP of the value for this parameter. The default value is 15M. 


The units default is M (minutes). 


SYSOUT (class) Specifies the SYSOUT class to which formatted reports are 
directed. Class A is the default. 


Conflicts Between Options 


After the operator enters the START command to begin MF/1 execution, the 
control options are merged from all sources. After this merge has been performed, 
it is possible that some conflicts may arise in that some parameters should not be 
used in conjunction to control a single MF/1 execution. When any of these situations 
occur, MF/1 selects compatible values for these parameters, and notifies the operator 
of the selection. The possible conflicts are as follows: 


CONFLICT PROBLEM MF/1 RESOLUTION 


NOREPORT and No way for installation to Change NOREPORT to REPORT 
NORECORD specified obtain measurement data (DEFER) 


STOP value specified is Indicates MF/1 termination Set STOP value equal to INTERVAL 


less than INTERVAL prior to obtaining any data value 
REPORT(DEFER) and SYSOUT will become Set STOP value equal to INTERVAL 
NOSTOP specified cluttered with unprinted value 

reports 


Need for Careful Choice of Certain Parameters and Options 


Care should be taken in specifying certain groups of MF/1 parameters. Though not 
causing conflicts, injudicious choices of these parameters can cause undesirable 
results. These include poor choices of: device class selection for monitoring devices, 
INTERVAL and CYCLE values, and STOP, INTERVAL, and REPORT values. 


INTERVAL and CYCLE Parameters 


Much of the data in the channel and device activity reports is statistically sampled. 
Since according to statistical theory the accuracy of sampled data increases with the 
number of samples taken of random events, an installation would expect to observe 
more precise results with decreased CYCLE time (for a fixed INTERVAL value), or 
with increased INTERVAL length (for a fixed CYCLE value). For example, 400 
samples taken of random independent events provide a value which, with 90% 
Confidence, should fall within 4% of the true value; 1,600 samples of random 
independent events decrease to 2% the expected range of error, with 90% confidence. 
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However, pure statistical predictions are not always applicable to a software J 
measurement tool such as MF/1 because the assumptions on which they are based 
(unbiased random independent samples and an infinite population) might not hold 
in an cperating environment. Bias might occur because MF/1 samples internal 
indications of external system events. Thus MF/1 values might not precisely 
approach the values measured by a hardware measurement tool. The independence 
assumption becomes less and less realistic as CYCLE gets very small. As CYCLE 
gets smaller, each sample is more likely to find the system performing the same 
functions as in the previous sample; therefore, the new sample adds little additional 
information. The use of a smaller CYCLE value (while holding INTERVAL 
constant) should not be detrimental to accuracy, but any increase in accuracy might 
be of questionable benefit when compared with the system overhead that is 
introduced. A reasonable minimum CYCLE is a function of the timing 
characteristics of the hardware being measured. 


Sample size can be increased by increasing INTERVAL length, by decreasing 
CYCLE length, or both. When decreasing CYCLE length, the installation should be 
aware that the increase in system degradation due to MF/1 operation could become 
significant, especially in the area of device measurements. At each sampling cycle, 
there is system overhead introduced due to the processing of the periodic inter- 
ruption, and due to the data collection that occurs after the interruption. Device 
data collection is the major contributor to this type of overhead. Installations with 
a large number of UCBs associated with devices generated with the system can use 
the following approximation of the total overhead (number of instructions 
executed) associated with each sampling cycle: 


Number of instructions ~ (10x D;) + (30x D>), ) 


where D; = number of UCBs associated with offline devices for monitored 


device classes, and 
number of UCBs associated with online devices for monitored 
device classes. 


D2 


Thus, particularly when the number of UCBs for monitored device classes is large, 
the CYCLE value should not be made too small. In particular, avoid specifying a 
CYCLE value of 50 milliseconds. 


The total overhead should be considered when the installation specifies the 
CYCLE value, so that total overhead for MF/1 sampling will not distort the normal 
system environment being measured. 


Device Class Selection: Since MF/1 overhead is directly related to the number of 
device classes being monitored, the DEVICE option device list should include only 
those devices that require monitoring. For example, if the user is not interested in 
monitoring character readers and communications equipment, NOCHRDR and 
NOCOMM should be specified in the device list. This specification will eliminate 
MF/1 overhead for those device classes. 


STOP, INTERVAL, and REPORT Parameters 


As was mentioned above, the specification of NOSTOP along with REPORT 

(DEFER) is considered a conflict by MF/1, because of the possible filling up of 

SYSOUT spool space. A similar problem can occur when the STOP value specified s) 
is very large (the largest specifiable value is 168 hours), the INTERVAL value is 

small, and REPORT (DEFER) is specified. 
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MF/1 Reports and SMF Records 


MF/1 produces feedback on the system activity data it monitors in the form of 
printed reports and/or SMF records. These reports/records are produced for each 
measurement interval and when MF/1 is terminated with an operator STOP 
command. The printed reports which can be produced by MF/1 are: 


CPU Activity 

Channel Activity 

Unit Record Device Activity 
Graphic Device Activity 

Direct Access Device Activity 
Communication Equipment Activity 
Magnetic Tape Device Activity 
Character Reader Device Activity 
Paging Activity 

Workload Activity (by performance group period, by performance group, or 
for the system as a whole) 


The SMF records which can be produced by MF/1 are: 


SMF70 — CPU Activity 

SMF71 — Paging Activity 

SMF72 — Workload Activity (one record for each performance group) 
SMF73 — Channel Activity 

SME74 — I/O Device Activity (one record for each device class for which data 


gathering was requested) 


Each SMF record contains information similar to the contents of the corresponding 
formatted report. Totals, averages, and percentages are not explicitly contained in 
the SMF records, but may be calculated from the explicit data. The precise formats 
of the SMF records are contained in OS/VS System Management Facilities (SMF). 
Elaboration of particular fields in these records may be obtained by consulting the 
descriptions of the corresponding fields in the following printed report descriptions: 


Each printed report has the following header information in common: 


Type of Operating System: The label OS/VSn, where n is the system 
indication. 

Release Number: The label RELEASE nn.11, where nn and 11 are the 
number and level. 

Date of Measurement: The date on which the measurements were started, 
in the form DATE mm/dd/yy. 

Time of Day: The time of day that the measurements were started, in the 
form TIME hh.mm.ss. 

Measurement Interval: The length of the interval after which unique sets of 
measurements are printed out, in the form INTERVAL mm.ss.ttt. The end 
of the measurement interval is the sum of the recorded start time and the 
interval length. 

Report Title: The identification of the report, as one of the ten MF/1 report 
types. 

Page Number: The page number of the report output, in the form 

PAGE xxxx. 
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system generation or initialization. The format is SYSTEM ID cccc. 
e@ Report Version: The two-digit revision level of the report, in the form MF/1 
VERSION nn. 


e System ID: The four-character SMF identifier associated with this system at ) 


All calculated numerical values in all MF/1 reports are rounded to the nearest 
printable value, unless otherwise noted in an individual report description. 
Asterisks are printed for numbers too large for the print field. 


CPU Activity Report 


This report provides information about the use of the central processing unit(s). 
The total CPU wait time that has taken place during an MF/1 reporting interval is 
generated for each CPU. The CPU wait time is also expressed as a percentage of the 
reporting interval time. A sample of this report is contained in Figure 4-1. Entries 
are included for each CPU which has been online at the end of at least one reporting 
interval since MF/1 was started. Numerical data is not printed for CPUs which 

were offline at the end of the reporting interval, or had any VARY activity during 
the interval. CPUs for which data is not printed have one of the following messages 
in the first data field: 


NOW ONLINE: Means that the CPU was varied online during this 
interval and is online at the end of the interval. 

NOW OFFLINE: Means that the CPU was varied offline during this 
interval and is offline at the end of the interval. 

OFFLINE: Means that the CPU has been offline for the entire J 
interval. 


The data fields in this report include: 


@ CPU Number: An integer (either 0 or 1), identifying the CPU in the 
system. This integer is the one produced by the STORE CPU ADDRESS 
(STAP) instruction (zero for a uniprocessor). 


e@ Wait Time: The amount of time during which the CPU is not executing 
instructions (PSW wait state bit is on) in hours, minutes, seconds, and 
thousandths of a second. 


e Wait Time Percentage: The fraction of the reporting interval that is 
represented by wait time. The range of values is 00.00 to 100.00. 


e CPU Serial Number: The 6-digit number obtained by the store CPU ID 
instruction (STIDP). This number coincides with the physical serial number 
stamped on the CPU and, in conjunction with the model number, permits 
unique identification of the CPU. 
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Part 4 


Channel Activity Report 


This report provides information about channel loading for all channels in the J 
system. Channel entries are included for each channel in the system which has been 

Online at least one observation cycle since MF/1 was started. Data is not formatted 

for channels which were offline at the end of the reporting interval, or had any 

VARY activity during the interval. Channels for which data is not printed have one 

of the following messages in the first data field: 


NOW ONLINE: Means that the channel was varied online during this 
interval and was online at the end of the interval. 

NOW OFFLINE: Means that the channel was varied offline during this 
interval and was offline at the end of the interval. 

OFFLINE: Means that the channel has been offline for the entire 
interval. 


Figure 4-2 contains a sample channel activity report. The data fields in this 
report include: 


e CPU Number: An integer (either 0 or 1), identifying the subject CPU by 
internal address. 


e@ Channel Number and Type: The channel number is the hexadecimal 
representation of the external channel address. Channel types are identified 
as BYTE MPX, SELECTOR, or BLOCK MPX for byte multiplexor, selector, 
and block multiplexor, respectively. oe 


e Channel Activity Count: The number of successful Start I/Os issued to the 
channel during the report interval. ‘“‘Sense” Start I/Os are not counted; 
however, redundant, successful Start I/O Fast Release instructions (condition 
code zero) are counted. Six significant digits are printed. A scale factor of M 
(millions) may be printed after the number. The range is zero to 999,999M. 
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e@ Percent Channel Busy: The percentage of time during the report interval in 
which the channel was busy. The percentage is derived by dividing the number 
of sampling observations during the reporting interval in which the 
channel was busy, by the total number of observations during the reporting 
interval. An observation is made at periods determined by the CYCLE key- 
word. The accuracy obtainable for “percent channel busy” is dependent 
upon the number of observations made (see discussion under “INTERVAL 
and CYCLE Parameters” above). A channel is considered busy if operating in 
burst mode at a sampling observation. Percent channel busy values are not 
produced for byte multiplexor channels. 


e@ Percent Channel Busy and CPU Waiting: The percentage of time during the 
reporting interval during which the channel was busy and, simultaneously, 
the CPU was in the wait state. (The CPU waiting portion of this reported value 
does not include the execution of the MF/1 sampling routine.). This value is 
used as a measure of I/O boundedness, and is calculated by dividing the 
number of observations during the reporting interval in which the channel 
was in burst mode (condition code 2 from a test channel instruction) and the 
CPU was simultaneously in the wait state, by the total number of observations 
during the reporting interval. An observation is made at periods determined 
by the CYCLE keyword. The accuracy obtainable for “percent channel busy 
and CPU waiting”’ is dependent upon the number of observations made (see 
discussion under “INTERVAL and CYCLE Parameters’ above). 


This value is not produced for byte multiplexor channels. 
The sample channel activity report also shows the standard heading CYCLE, which 


indicates the requested time between sampling observations. This is the value 
specified by the CYCLE keyword. The range of values is 0.050 to 0.999 seconds. 
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I/O Device Activity Reports 


The reports provide information about I/O device loading for all devices in the 
device classes selected by device class keywords. In addition to device activity 
measures, the report contains a measure of contention delay which is tabulated by 
device, but may be caused by hardware contention for any unit (channel, control 
unit, or device) in the path to the device. Device entries are included for each device 
which has been online at least once since MF/1 was started. Data is not formatted 
for devices which were offline at the end of the reporting interval, or had any 
VARY activity or dynamic device reconfiguration during the interval. Devices for 
which data is not printed have one of the following messages in the first data field: 


NOW ONLINE: Means that the device was varied online during this 
interval and was online at the end of the interval. 

NOW OFFLINE: Means that the device was varied offline during this 
interval and was offline at the end of the interval. 

OFFLINE: Means that the device has been offline for the entire 
interval. 


Note: MF/1 sampling overhead is directly related to the number of devices in the 
device classes being monitored, whether online or not. For example, if an 
installation is interested in monitoring only tape devices, and specifies ‘NODASD’, 
then a large number of direct access devices does not increase MF/1 sampling 
overhead. 


Figure 4-3 contains a sample I/O device activity report (here, the Direct Access 
Device Report; for the 2305 Fixed Head Storage Device, multiple device entries 
are made and the reported data reflects each device exposure). The data fields 
in the report include: 


e Device Address: The unique three character hexadecimal device address 
which identifies a physical I/O device. 


@ Volume Serial Number: The six character volume serial number of the 
volume mounted on the device at the end of the reporting interval. This 
field appears only in reports for direct access and magnetic tape devices. 


e Device Activity Count: The number of successful Start I/Os issued to the 
device during the report interval. ‘“‘Sense” Start I/Os are not counted; 
however, redundant, successful (condition code zero) Start I/O Fast Release 
instructions are counted. 


e Percent Busy: The percentage of time during the report interval in which 
the device was busy. The percentage is derived by dividing the number of 
observations during the reporting interval in which the device was busy. 
by the total number of observations during the reporting interval. Observa- 
tions are made at periods determined by the CYCLE keyword. The accuracy 
obtainable for “percent busy” is dependent upon the number of observations 
made (see discussion under “INTERVAL and CYCLE Parameters’ above). 
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@ Average Queue Length: The average number of requests which are enqueued 
and waiting to be serviced on the subject device at any given time. This value > 
is a Measure of contention at any of the hardware units (channel, control 
unit, or device) in the path to the device. It is calculated by dividing the 
accumulation of the requests enqueued against this device at CYCLE 
observations, by the total number of observations made during the report 
interval. The accuracy obtainable for “‘average queue length” is dependent 
upon the number of observations made (see discussion under “INTERVAL 
and CYCLE Parameters” above). 


The sample I/O device activity report also shows the standard heading CYCLE, 
which indicates the requested time between sampling observations. This is the 
value specified by the CYCLE keyword. The range of values is 0.050 to 0.999 
seconds. 


Paging Activity Report 


This report provides detailed information about the demands made on the system 
paging facilities and the utilization of real and auxiliary storage during the 
reporting interval. Figure 44 contains a sample paging activity report. Explanations 
of the fields appearing in the report are as follows: 


Main Storage Paging Rates 


e Pageable System Areas: These are areas of main storage not associated with a 
single address space. They include the pageable link pack area, the link pack 
area directory, the link pack area extension, the pageable BLDL list, and the J 
common storage area. Virtual I/O and non-virtual I/O paging rates are 
provided for these areas, though the Virtual I/O counts for these areas will 
always be zero in MVS. (In MVS, Virtual I/O is applicable only to address 
spaces.) 


e@ Address Spaces: These are areas of main storage associated with individual 
address spaces. Virtual I/O and non-virtual I/O paging rates are provided for 
these areas. 


e Page Reclaim Rate: This is the per-second rate of page frames that are 
disconnected (stolen) from an address space or the system pageable area, but 
are retrieved for reuse before being re-allocated. The reclaim rate shows the 
number of non-initial-reference page faults or logical GETs which do not 
require reading from auxiliary storage. The range of values is 0.00 to 
999,999. 


e@ Page Reclaim Percentage: The percentage of the total system reclaim rate for 
each part of the total. 


@ Swap Page-in Rate: The per-second rate of pages read into real storage, as a 
result of address space swap-ins. 


e Non-swap Page-in Rate: The per-second rate of pages read into real storage, 
exclusive of address space swap-ins. 


e@ Total Page-in Rate: The per-second rate of total pages read into real storage. - 
This rate is the sum of swap and non-swap page-in rates. 
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Total Page-in Percentage: The percentage of the total system page-in rate, for 
each part of the total. 


Swap Page-out Rate: The per-second rate of pages written to auxiliary storage 
as a result of address space swap-outs. 


Non-swap Page-out Rate: The per-second rate of paging out of real storage, 
exclusive of address space swap-outs. 


Total Page-out Rate: The per-second rate of total pages written to 
auxiliary storage. This is the sum of the non-swap and swap page-out rates. 


Total Page-out Percentages: The percentage of the total page-out rate for 
each part of the total. 


The ranges for all the above rates are from 0.00 to 999,999 and are expressed 
as an average rate for the interval. Explanations of the meanings of the various 
swapping sub-categories follow: 


Non-VIO Page-in: A page transfer from auxiliary to real storage which occurs 
as a result of a page fault, PGLOAD, or PGFIX, except those for pages of 
VIO data sets. Note that if there are concurrent requests for the same page, 
the first generates a page-in, and all the rest are considered reclaims. 


Non-VIO Page-out: A page transfer from real to auxiliary storage that occurs 
as a result of a PGOUT (including page stealing and other RSM generated 
page-outs), for pages other than those of a VIO data set. 


Non-VIO Reclaim: A request for a page as a result of a page fault, PGLOAD 
or PGFIX, which is satisfied without starting a new page-in, except those 
recovered by explicit VIO reclaim. 


VIO Page-in: The transfer of a VIO data set page from auxiliary to real 
storage, resulting from a page fault or a PGLOAD on a VIO window. VIO 
pages which are swapped in are not included. 


VIO Page-out: A transfer from real to auxiliary storage of a VIO data set 
page as a result of a PGOUT (including stealing and other RSM generated 
page-outs) on a VIO window page. VIO pages transferred as a result of a 
swap-out are not included. 


VIO Reclaim: A VIO request for a real storage data set page which was 
satisfied without page-in by means of the explicit VIO reclaim interface. 


Auxiliary Storage User Pool 


The user pool is one of three pools of paging data sets that comprise the total 
paging space. The other two pools are the system pool and the duplex pool. The 
duplex pool contains a copy of the system pool. 


The following values are snapshots of the end of the measurement interval. These 
values are probably different from the average during the interval. In particular, 
the swap-in of the MF/1 address space will decrease the number of unused frames. 
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e Page Slots: The heading of auxiliary storage page slots for each category. 
Its values consist of snapshots observed at the end of the measurement 
interval. The range of values is from 0 to 99,999,999. 


e@ Available Slots: The number of page slots that do not contain any data pages 
and that are available for use. (When the auxiliary storage user pool contains 
overflow from the system pool of paging data sets, the count of available 
slots will be higher than the actual number of available slots.) 


e VIO Slots: The number of auxiliary storage page slots that contain pages 
for VIO data sets. 


@ Non-VIO Slots: The number of auxiliary storage page slots in the user pool 
that contain pages that belong to address-space virtual storage. 


e@ Unavailable Slots: The number of auxiliary storage page slots that do not 
contain any data pages, and not available for use because of permanent I/O 
errors. 


e@ Total Slots: The sum of all auxiliary storage page slots in the user pool of 
paging data sets. 


e Percent Page Slots: The percent of total auxiliary page slots in each category. 


Pageable Main Storage Counts 


The following values are snapshots at the end of the measurement interval. These 
values are probably different from the average during the interval. In particular, 
the swap-in of the MF/1 address space will decrease the number of unused frames. 


e@ Unused Frames: The number of pageable real storage frames not allocated 
to any address space, or to the pageable system area. 


e@ Data Pages: The number of pageable real storage frames allocated to swapped 
in address spaces, common area, or dynamic SQA. 


e@ Total Frames: The sum of all real storage frames in the system. 


e Page Frames: The number of real storage frames in each category. It is 
observed at the end of the measurement interval. The range of values is 
0 to 4,096. 


e Percent Page Frames: The percent of total real storage frames in each 
category. 


Swap Counts 


e@ Swaps: The number of address space swap sequences, where a swap sequence 
consists of an address space swap out and swap in. The range of values is 
0 to 9,999,999. 


e@ Average Pages per Swap-out: The average number of pages swapped in for 
each address space swap in. The range of values is 0 to 4,096. 


@ Average Pages per Swap-in: The average number of pages swapped in for 
each address space swap in. The range of values is 0 to 4,096. 
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Part 4 


Workload Activity Report ) 


This report provides information about the system workload activity, and its 
relationship to the installation-specified performance objective for each performance 
group period. This information can be used to evaluate and modify the installation 
performance specification (IPS). The report may be produced in any one of three 
different levels of detail, specified by the parameters indicated below from the most 
detailed report to the least detailed report: 


Performance group period level: WKLD(PERIOD) 
Performance group level: WKLD(GROUP) 
System summary report: WKLD(SYSTEM) 


The performance group period report is the most detailed workload activity report 
provided. It prints workload information broken down by performance group 
period — that is, information is provided for transactions associated with each 
performance group period defined in the IPS. The performance group report pro- 
vides an intermediate level of detail. It provides information for all transactions 
associated with each performance group defined in the IPS. The system summary 
report is the least detailed report provided. It provides information applicable to the 
system as a whole during the measurement interval. 


The workload activity report fields provide two sets of information at each 
report level: 


® Active Transactions: Information on active transactions includes only data 
for transactions that were active during the reported MF/1 interval. There 
are four fields: Service in Interval; Average Transaction Service Rate; - 
Workload Level; Average Transactions. 


e Ended Transactions: Information on ended transactions includes data for 
transactions that may have been active in previous MF/1 intervals and for 
only part of the currently reported interval. Ended transactions include two 
fields: Ended Transactions and Average Time of Ended Transactions. 


Figure 4-5 contains a sample workload activity report, at the performance group 
period level. Explanations of the fields appearing in the report follow: 


e Performance Group Number: (This is provided in the performance group 
and performance group period level reports only.) — The identification of the 
installation defined performance group which defines the prescribed 
treatment for a class of users. The range of values is 1 to 255. 


e Performance Group Period: (This is provided in the performance group 
period level report only.) — A number identifying an identifiable portion of 
the life of a transaction, which the installation has singled out to be associated 
with a particular performance objective. The range of values is 1 to 8. 


@ Service in Interval: The total number of service units absorbed by 
transactions during the measurement interval. The range of values is 0 to 
240. Only 7 significant digits are printed in the report. Higher values are 
shown as millions of service units by an M following the number. 


e Average Transaction Service Rate: The total number of service units absorbed 
by all transactions in the period, group, or system, divided by the active time 
of all transactions. The entire “‘transaction active” time is equal to the total - 
transaction active time accumulated by all associated transactions. Each 
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transaction’s “transaction active” time is equal to the total time during which 
the transaction was in real storage, added to any swapped-out time during 
which the transaction was not in a “wait” state. It does not include time 
between job steps, for batch transactions. Notice that the service rate 
provided to all transactions (in the period, group, or system) is equal to the 
“average transaction service rate” times the “‘average transactions”. The 
range of values is 0 to 1013 minus one. Only 6 significant digits are printed. 
Higher values are shown as millions of service units per second, by an M 
following the number. (This value is not rounded; it is truncated.) 


e Workload Level: The level in the IPS at which associated performance 
objectives are being satisfied. The level indicated for each performance group 
period is the normalized service rate for all transactions in that period. The 
levels given for the performance group and the system total are averages of the 
“period” workload levels weighted by accumulated service. The range of 
values is 1.00 to 224.00. The label EST is shown after the value for estimated 
values. An estimated value is given where the same service rate is specified in 
the IPS for more than one workload level — that is, when the performance 
objective is horizontally graphed. fs 

@ Average Transactions: The average nuniber of transactions simultaneously 
active in the measurement interval. It isthe quotient of the total active time 
spent by all transactions (in the performance group period/ performance 
group/system) divided by the measurement interval time. The range of values 
is 0.00 to 224. Only 6 significant digits are printed. Higher values are shown 
as millions of transactions by an following the number. 

e Ended Transactions: The total number of transactions which terminated 
during the measurement interval. The range of values is O to 2”. Only 6 
significant digits are printed. Higher values are shown as millions of 
transactions by an M following the number. 


e@ Average Time of Ended Transactions: The average transaction elapsed time 
of all transactions which terminated during the measurement interval. A trans- 
action’s “transaction elapsed”’ time is the real time interval between the start 
and end of the transaction. The maximum number of hours is 999. 


The standard report heading appears with one additional heading: 


IPS ID: This is the member of SYS1 .PARMLIB that contains the controlling 
IPS (i.e., IEATPSxx). 


Data values in this report are not printed for performance groups or performance 
group periods which would have all values equal to zero. The word ZEROS is 
printed in the first field following the performance group or performance group 
period number. 


The workload activity report may be a “‘short” report (it may not cover the 
entire reporting interval) if the Workload Manager of the SRM stopped collecting 
statistics as a result of a change in the IPS during the report interval. If this is the 
case, the INTERVAL field of the header contains the time interval during which 
statistics were being collected. 
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Using MF/1 “ 


The uses to which MF/1 can be put are dependent upon the needs and goals of the 
individual installation. The following sections indicate hypothetical examples of use 
of each of the MF/1 report types. The examples are not meant to reflect actual 
figures or relationships, but rather to indicate the possibilities for tuning that MF/1 
can provide. The indicated methods of analysis are not the only ones, and are not 
necessarily the best ones, but are suggestive of the possibilities that MF/1 provides. 


Using the CPU Activity Report 


An installation wishing to monitor its CPU utilization during the afternoon hours 
of 1:00 to 3:00 (its peak period) requests the collection of CPU usage data by 
having the operator enter the following command at 1:00 P.M. 


START MF1.EXAMPLE, , (NOPAGING,NOCHAN,NOWKLD, 
NODEVICE, INTERVAL(30M), STOP(2H)) 


Assuming that the installation is running with the IBM-supplied MF/1 cataloged 
procedure and the IBM-supplied IRBMF100 parmlib member, the following 
options will control the MF/1 execution: 


CPU 
NOCHAN 

NODEVICE 

NOPAGING 

NOWKLD J 
CYCLE(250) 
INTERVAL (30M) 

MEMBER (00) 

OPTIONS 

NORECORD 

REPORT(DEFER) 

STOP(2H) 

SYSOUT(A) 


The CYCLE Parameter will have no effect upon execution, since neither channel 
nor device statistics are being gathered. 


This list of options will result in 4 CPU activity reports being printed after MF/1 
termination, based upon statistics gathered each half-hour for two hours. 


The installation finds, from averaging CPU wait time percentages, that the CPU is 
in the wait state 30% of the time during this peak period. Determining that this is 
unacceptable, the installation creates anew PARMLIB member IEAOPT xx and 
specifies the CPU resource factor coefficient (RFC) in this new member as: 


CPU = 9.9 


Since previously the value of this coefficient was equal to 0.1, the installation 
reasons that this change will cause the SRM to weight CPU imbalances more heavily 
in making swapping decisions. The installation places the new member into ) 
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operation, and observes the effect upon the system by requesting a full complement 
of MF/1 reports for a subseugent 1:00 to 3:00 peak period. To obtain these 
reports, the operator enters: 


START MF1.EXAMPLE, , ,(INTERVAL(30M),STOP(2H)) 


This execution produces 4 reports each of CPU, channel, device, paging, and 
workload activity. Analyzing the CPU activity report, the installation finds that CPU 
utilization has been raised to 100%. However, analyzing the workload activity report 
(see Workload Activity Report, below), the installation finds that the service rate 
provided to a high priority group of users has been seriously degraded. The instal- 
lation makes the inference that this resulted from the RFC change. Therefore, the 
installation decreases the CPU resource factor coefficient as follows: 


CPU = 5.0 


After placing the modified IEAOPTxx member into operation and monitoring 
during a subsequent peak period, the installation finds that the service rate provided 
to the high priority performance group is at an acceptable level. Furthermore the 
CPU utilization, though not so high as at the last monitoring, is still substantially 
above the original level. 


Using the Channel Activity Report 


An installation wishes to analyze the utilization of its I/O channels. It decides to try 
to obtain about 2400 samples as a basis for the printed figures in each printed 
channel report. To achieve this number of samples in each printed report, a CYCLE 
value of 500 milliseconds is chosen (2 samples per second), and a reporting 
INTERVAL length of 20 minutes (1200 seconds, 2400 samples) is selected. (See 
discussion under “Interval and Cycle Parameters”, above.) The system operator 
enters the following command to initiate MF/1 operation, at four different 

periods during the day: 


START MF1.EXAMPLE, , (NOCPU,NOPAGING,NOWKLD, 
NODEVICE, INTERVAL(20M) ,CYCLE(500),STOP(1H) 


Assuming that the installation is running with the IBM-supplied MF/1 cataloged 
procedure and IRBMF100 parmlib member, the following options will control the 
MF/1 operation: 


NOCPU 

CHAN 
NODEVICE 
NOPAGING 
NOWKLD 
CYCLE(500) 
INTERVAL(20M) 
MEMBER(OO) 
OPTION 
NORECORD 
REPORT(DEFER) 
STOP(1H) 
SYSOUT (A) 


Part 4: How to Use the System Activity Measurement Facility (MF/1) 225 


VS2.03.807 


This list of options will result in three channel activity reports being printed after 
MF/1 termination, based upon statistics gathered every twenty minutes for one 
hour. 


The installation finds, in comparing the percent channel busy indications from 
each channel, during each of the four one-hour periods of MF/1 activity, that one 
particular channel (channel 2) has a continually significantly higher percent channel 
busy figure than the other channels. The installation attempts to correct this 
situation by increasing the value of the I/O resource factor coefficient in the 
parmlib system tuning parameters member (parmlib member IEAOPTxx) as 
follows: 


] IOC = 5.0 (previously, the value was 0.1). 


After an IPL with the modified IEAOPTxx member, the installation monitors 
the effect of the change upon the system by again requesting that the operator enter 
the previous command four times during the day, each time obtaining three printed 
channel activity reports. 


Again, the installation finds that the utilization of channel 2 is too high. This 
indicates that the SRM has been unable to improve the imbalance by its swapping 
recommendations. To investigate the problem further, the installation requests 
device activity reports, as explained below. 


Using the Device Activity Report 


In pursuing the problem outlined under “Channel Activity Report” the installation 
notes that both tape and direct access devices are connected to channel 2. There- 
fore, the installation requests that the operator enter the following START MF/1 
command a number of times, to analyze the device activity on this channel: 


START MF1.EXAMPLE, , (NOCPU,NOCHAN,DEVICE(NOUNITR, 


NOCOMM,NOGRAPH,NOCHRDR) NOPAGING,NOWKLD, 
INTERVAL(20M),CYCLE(500),STOP (1H)) 
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Assuming IBM supplied MF/1 cataloged procedure and IRBMF100 parmlib member, 
the following options will control the MF/1 operation: 


NOCPU 

NOCHAN 

DEVICE (NOCHRDR,NOCOMM,DASD,NOGRAPH,TAPE,NOUNITR) 
NOPAGING 
NOWKLD 
CYCLE(500) 
INTERVAL (20M) 
MEMBER (00) 
OPTION 
NORECORD 
REPORT (DEFER) 
STOP(1H) 
SYSOUT (A) 


This list of options will result in three tape device activity and three direct access 
device activity reports being printed after MF/1 termination, based upon statistics 
gathered every twenty minutes for | hour. 


The installation finds that two of the direct access devices on channel 2 both 
have high percent busy figures, and high average queue length figures. The instal- 
lation checks the volumes indicated as mounted on these devices, and finds several 
frequently used system data sets on each. After relocating some of these data sets, 
subsequent MF/1 analysis shows a better balance of I/O device and channel 
utilization. 


Using the Paging Activity Report 


This report provides a wide breadth of information not susceptible to simple 
interpretation. An installation could use it, for example, to analyze the amount of 
swapping overhead that is occurring. It could also analyze the change to this over- 
head that is produced when certain System Resources Manager parameters are 
varied (for example, the interval service value (ISV) in the IPS). The installation 
might similarly wish to analyze the percentage of auxiliary storage slots that are 
unused, in view of the relation of this percentage to the efficiency of operation of 
the Auxiliary Storage Manager. (A low percentage of unused slots could result in an 
excessive amount of ASM overhead, in trying to access these unused slots.) 
Alternatively, the installation might wish to compare paging rates indicated by 
this report with the profile of user activity provided by the Workload Activity 
Report, to analyze possible correlations between high paging rates and high 
percentages of active users from certain performance groups. 
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Using the Workload Activity Report 


This report, like the paging report, is susceptible to a wide range of uses. Some 
examples follow: 


@ The distribution of transactions among performance groups is found under the 
column labeled “average transactions” and in the row labeled “ALL” in the 
performance group period column. The distribution can give a general profile 
of the system workload at different times of the day. In contrast, the distri- 
bution of total service among performance groups (found under the “service 
in interval” column, and in the row labeled “ALL” in the performance group 

: period column) can tell the installation which performance groups are really 
getting the bulk of the system resources. 


@ The total service provided to all users in the measurement interval is found 
under the “service in interval” column and in the “‘system total’ row. This 
information can provide a basis for comparing system throughput under 
different workload conditions. By comparing this figure for similar MF/1 
reporting interval lengths, the installation can determine whether changes 
made to impfove the system configuration have had the desired effect on 
throughput. 
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This blank leaf represents page 229 which was deleted by Supervisor Performance *2. 
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Part 5: System Performance Factors 


Part 5 contains discussions of factors that affect system performance and discussions 
of certain tools that can measure performance. Each discussion includes guidelines, 
and rationale. Some discussions also include questions and answers. Since 

MVS is significantly different from MVT, the discussions emphasize new 

aspects of the system, such as VIO, VSAM catalog, and the pageable link pack area. 
The performance information is based on design analysis; that is, on projections 

of how the system is supposed to work. Some of these ideas will change as system 
experience is gained. These new insights, based on system measurements, will first 
appear in Installation Newsletters as tuning guidelines. 


The following performance topics are included in Part 5, in this order: 


The Pageable Link Pack Area: Its Advantages and Uses 
VIO Performance 

Device Allocation Performance 

VSAM Catalog Performance 

How SMF Can Supplement MF/1 

The Use of GTF to Track Sysevents 

TCAM Tuning Considerations 

TSO and Batch Service Trade-offs Via the IPS 
Miscellaneous Performance Guidelines 


The information previously here and through page 239 in the base publication 
is now incorporated in “Part 2.1: Auxiliary Storage Management Initialization”’. 
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This blank leaf represents pages 232 - 239 which were deleted by Supervisor Performance *2. 
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The Pageable Link Pack Area: Its Advantages and Uses 


The pageable link pack area (PLPA) contains most of the frequently used control 
program routines. All IBM-supplied transient SVC routines and appendages now 
reside in the PLPA. The result is that the transient area contention problem of MVT 
has been eliminated. 


It’s desirable to place all commonly used reentrant LINKLIB and CMDLIB 
modules* in the PLPA because of the following advantages. (An opposing 
philosophy on the use of the fixed LPA is described later in this topic.) 


The length of time that a page occupies real storage depends on its frequency 
of use. If the page is not used over a period of time, the system will reuse 
(steal) the real storage frame that the page occupies. 


The most frequently used PLPA modules in any given time period will tend to 
remain in real storage. 


PLPA paged-in modules avoid Program Fetch overhead. 


Two or more programs that need the same PLPA module share the common 
PLPA code, thus reducing the demand for real storage. 


The main cost of unused PLPA modules is paging space, since only auxiliary 
storage is involved when modules are not being used. 


All modules in the PLPA are treated as reentrant in MVS; that is, 

PLPA pages in real storage are recognized by the system, the “change”’ bit 
is ignored, and PLPA page-out is avoided. This action reduces the overall 
paging rate compared with modules in other libraries. 


Recommendations 


The following recommendations should improve LPA performance: 


Copy frequently and moderately used reentrant** modules from LINKLIB and 
CMDLIB to LPALIB. OS/VS2 System Programming Library: Storage 
Estimates lists some of the control program modules that are already packaged 
in LPALIB and those that may be placed there. Low-usage TSO com- 

mand processors and low-usage user programs probably should not be 

placed in LPALIB. The reasoning is as follows. 


*See an alternative suggestion on the placement of some PLPA modules and 
CMDLIB modules later in this topic. 


**Preferably the modules should be refreshable, since a reentrant module is allowed 
to modify itself if it holds a global (cross-memory) lock during the modification. 
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Pageable Link Pack Area (continued) 


When code in the PLPA is not continually referenced by multiple address 
spaces, it will tend to be stolen. The reason is that individual address spaces 
typically get swapped out (without the PLPA pages they reference) and, as a 
result, one address space can’t maintain the referencing frequency necessary 
to prevent page stealing. When an address space is swapped back in, and 
most of the code it references has been stolen, the result is a very 
time-consuming serial sequence of page faults. 


e An alternative philosophy is to allow low-usage CMDLIB and low-usage user 
modules to remain in their libraries and be fetched into the user’s subpools, 
instead of being placed in the PLPA. The result would be that the TSO 
commands and user code would be swapped in and out with the address 
space. This action would virtually eliminate the serial page-fault delays. A 
secondary advantage is that the SRM could more accurately estimate the 
real storage implications of swapping such an address space into or out of 
real storage. 


e@ Minimize page faults and disk arm movement by specifying module packing 
through the IEAPAKOO member of parmlib. Module packing reduces 
page faults by placing in the same virtual page those small modules (less than 
4K bytes) that refer to each other frequently. In addition, module groups 
that frequently refer to each other but which exceed 4K bytes in combined 
size can be placed in adjacent (4K) auxiliary storage slots to reduce seek 
time.* Thus, use of the PAK list should improve performance compared with 
the simple loading of the PLPA from LPALIB. (See the description of parmlib 
member JEAPAKOO in the Initialization chapter. The IEAPAKOO description 
includes a complete list of module names and their functions that are included 
in the IBM-supplied member.) 


If your installation uses ISAM, you may wish to add the following six pack- 
groups to parmlib member IEAPAKOO. Use the syntax rules listed under 
that member in the Initialization chapter. 


(1GG0192A,1GG0192B,1GG0192C), 
(1GG0192F,1GG0192G,IGG0195T,|GGO195U), 
(1GG0196C,1GG0196D,1GG0195G,1GG0196G,1GGO195D), 
(1GG01928,1GG01929,1GG01924), 
(1GG02021,1GG0202N,1GG0202J), 
(1GGO202K,|GG0202L,!|GG0202M) 


e Use within reason those parmlib lists that speed the search for listed modules 
at the expense of the unlisted modules. The lists include the modified link 
pack area list (IEALPAxx), the fixed LPA list (IEAFIXxx), and the load list 
(IEALODO0). (For information on these lists, see IEALPAxx, IEAFIXxx, and 
[EALODO0 in the Initialization chapter.) NIP builds and chains contents 
directory entries (CDES) for modules in these lists, one CDE per module. 


*Adjacent slot location, although likely, is not guaranteed. For further information, 
see “How the PLPA Is Loaded” later in this topic. 
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Pageable Link Pack Area (continued) 


Later, when a module is requested, the Program Manager serially searches the 
active LPA. The active LPA is ordered as follows: 


1. modules loaded from PLPA 
2. IEALODOO list 
3. fixed link pack area list 


4. modified link pack area list 


Note: This sequence is a part of the overall module search sequence listed 
later in this topic under the heading ““The VS2 Module Search Sequence’”’. 


If the CDE search is unsuccessful, the Program Manager then uses a hashing 
technique to search the LPA directory on direct access. Note that modules 
in the modified LPA list, the fixed LPA list, and the IEALODOO list tend to 
be found fairly rapidly (except for very long lists), but at the expense of 
modules that must be found in the LPA directory. It’s undesirable to make 
these parmlib lists excessively long, since the CDE search will be prolonged 
and the LPA directory search will be delayed. It’s probably best to limit the 
three lists to moderate-use modules, since high usage PLPA modules will tend 
to remain in real storage and thus in the active link pack area list. 


@ You may use the fixed LPA to buy reduced page-fault overhead and increased 
performance at the expense of some real storage. Such tradeoff would be 
desirable with a system that tends to be CPU bound. The condition of being os 
CPU bound implies that real storage is not also overcommitted. Therefore, 
it would seem desirable to divert some real storage from possible use by 
additional address spaces, and use the diverted storage for LPA module 
residence. (You can run MF/1 to determine the relative availability of CPU.) 
Implement the tradeoff by placing moderate-usage LPALIB modules in the 
fixed LPA (via parmlib member IEAFIXxx), instead of in the pageable LPA. 
High usage PLPA modules probably need not be listed in IEAFIXxx, since 
they may be referenced frequently enough to remain in real storage anyway. 
A large fixed LPA means less real storage will be available for pageable 
programs. Accordingly, the System Resource Manager will maintain fewer 
address spaces in real core than would otherwise be the case. No loss in 
throughput should occur, however, as long as CPU utilization remains 
reasonably high. 


Note that this suggestion represents an opposite philosophy to that 
described earlier, in which all moderate-use reentrant modules would be 
placed in LPALIB. 


The STIMER and TTIMER modules (IGCO004F and IGC0004G, 
respectively) are especially good ones to put in the fixed LPA because their 
design takes advantage of that placement to significantly improve the 
performance of the timer function. To place the modules in the fixed LPA, 
include their names in the IEAFIXxx member. 
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The VS2 Module Search Sequence 


The Program Manager searches for a requested module (requested in EP* form 
without DCB) in the following sequence. Note that the search of the active LPA 
queue in real storage takes place before the search of the PLPA directory. 


1. job pack area queue (JPAQ) 
2. tasklib(s), steplib, joblib 
3. active CDE queue (via a serial search). This queue includes: 
a. modules loaded from PLPA 
b. IEALODO0 list 
c. fixed LPA (FLPA) list 
d. LPA extension (also called the modified LPA, or MLPA) 
4. pageable LPA (via a hashed search of the LPA directory) 


5. LINKLIB and libraries concatenated to it via LINKLSTxx members 


How the PLPA Is Loaded 


The Program Manager’s resource initialization module (or RIM) “loads” PLPA from 
high virtual addresses to low. It starts with the pack groups listed in the IEAPAK00 
list, continues with the nonpack modules in LPALIB, and finishes with the link 
pack directory. 


The size of each pack group is determined, and each page is filled from low 
address to high. There is never any overlap of pack groups; that is, the second of 
two pack groups always starts at the next page boundary, possibly leaving a gap 
that the RIM will try to fill later with small non-pack modules. 





*EP means the entry point parameter of an ATTACH, LINK, LOAD, or XCTL 
macro. 
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The LPALIB modules that are not listed in IEAPAKOO are loaded next, from 
high virtual address to low, starting with the modules that are larger than 4K. 
The modules sized between 3K and 4K are then loaded. These modules may either 
fill 3K—4K gaps within a previously loaded pack group or be placed on a new 
virtual page. Lastly, the smaller modules are loaded in descending size order to 
try to fill gaps in the loaded pack groups. In each case the search is for a gap 
greater than each size value in bytes, as follows: 


4096 
3584 
3072 
2560 
2048 
1536 
1024 
512 
256 
128 
64 

0 


After all modules have been loaded, the link pack directory is built. 


During the load process, the Program Manager RIM forces page-outs of 100K 
bytes at a time. The Auxiliary Storage Manager (ASM) does the actual loading of 
the paging data set. (Real frame stealing may interfere with this process.) The 
forced-out pages will probably be placed in contiguous auxiliary storage slots, from 
low slot address to high, on the page data set(s) that will hold the PLPA*. 


Figure 5-1 illustrates the relative positions of two pack groups, composed of 20 
module each, plus 360 LPA modules (before backfilling) that are not in pack 
groups, and the LPA directory. The figure shows the relative positions of the 
modules and the LPA directory in virtual storage and in the PLPA page data set. 





*Ideally, the PLPA should be placed on a single page data set on a single device. 
This will happen if the first-named page data set (specified at IPL or sysgen) is 
sufficiently large to hold the entire PLPA. If it is not, the overflow will go on 
another page data set, possibly on another device. Since the LPA directory is 
paged out with the last 100K block, such PLPA separation could degrade 
performance, particularly if the overflow device is slower than the primary 
device. 
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SYS1.LPALIB 


Contains: modules 1— 400 


Virtual Storage 
after Loading by 
Program Manager 


four pages of LPA directory 


349 non-pack modules 
(# 41—400) arranged 
for best fit and least 


span 


lower virtual 
addresses 








700K 






pack group 2 
order of the 
loading 











modules # 21—40 
with five modules 
from # 41—400 
to fill gaps 


100K 


pack group 1 





modules # 1—20 
with six modules 
from # 41—400 


higher virtual to fill gaps 


addresses 





SYS1.PARMLIB (IEAPAKOO) 


Contains: Pack Group 1 Names (modules 1 —20) 
Pack Group 2 Names (modules 21 — 40) 


Page Data Set 
after Forced 
Page- Outs 


lower auxiliary 
addresses 
pack group 2 
100K 
pack group 1 


most of the 349 
non-pack modules 


(# 41—400) arranged 
in contiguous slots 
if possible 700K 


LPA directory | higher auxiliary 
addresses 


Note: Modules are transferred to auxiliary storage in blocks of 100K bytes. 


Figure 5-1. Illustration of the Loading of the PLPA 
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VIO Performance 


The use of VIO has both advantages and disadvantages. The installation must decide 
whether the advantages outweigh the disadvantages for its particular applications. 


Advantages 


VIO offers the following advantages: 


Virtual I/O pages tend to stay in real storage, if pages are not frequently 
stolen without being reclaimed. This gives VIO at times the effect of a 
very large number of buffers. With real data sets, on the other hand, 
output is done immediately, and on input, buffers are reused. 


DADSM overhead is minimized. 


VIO can improve the CPU efficiency of a user program that has a relatively 
small blocking factor. With a simulated 3330, with 9 blocks or more per 
track, VIO uses fewer instructions per track than conventional I/O. With 
fewer than 9 blocks per track, conventional I/O may be more efficient than 
VIO, provided that VIO data does not remain in real storage and real I/O 
occurs to a paging data set. 


The conventional serialization required by Allocation is not required for VIO 
(see performance topic “Device Allocation’’). 


The use of paging algorithms, such as ASM’s slot sorting, should speed up 
VIO operation, compared with conventional I/O (EXCP) by reducing device 
delays. For output, simulated data transfer can occur without waiting for 
real I/O to occur to paging space. 


VIO can facilitate improved DASD space management by the installation. 
If all temporary data sets use VIO, the installation can add to the paging 
space all of its DASD space previously used for temporary data sets. This 
should give the system at least as much VIO space as required. When VIO 
usage is low and other paging requirements are high, the space will 
automatically be used for non-VIO system paging needs. 
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Since auxiliary slots for VIO are allocated by ASM only as they are 
required (when the window is to be paged out) it may be possible to commit 
less DASD space for temporary data sets than with conventional I/O. 
Normally, a programmer allocates DASD space to handle a peak data set 
size, when in fact only a small portion of that space may be used. The space, 
however, remains reserved and cannot be used for other purposes. By using 
VIO, the programmer may still purposely overestimate data set size to insure 
he will not run out. However, he can be certain that only the space needed 
for data at any moment will be allocated. 


By examining slot usage (through the MF/1 Paging Activity report), the 
installation may be able to remove some of the previously “wasted’’ DASD 
space. It would then be able to utilize the space for other purposes, and still 
support as many temporary data sets as it did previously. (See Part 4: How 
to Use the System Activity Measurement Facility, Paging Activity Report, for 
additional information. In using MF/1 data for this purpose, the user should 
note that the Auxiliary Storage User Pool portion of the MF/1 Paging Activity 
Report indicates a snapshot of slot usage at the end of the report interval. 
Slot usage is likely to vary during a report interval.) 


e The JCL SPACE parameter is enforced for VIO, as it is for conventional 
access methods. There is also a default space allocation for VIO if the 
parameter is not specified. The fact that the SPACE parameter (specified or 
defaulted) is enforced gives the installation some protection against program 
bugs which could cause a write loop and saturate the paging space. Note that 
the maximum possible size for one VIO data set is a single volume on the 
simulated device. 


e VIO alleviates the SCRATCH SYS Problem. If an abnormal system termination 
occurs, there are problems associated with the deallocation of existing real 
system-named temporaries. For a batch installation, a warm start must be 
done (with the same packs up) to cause deallocation. Otherwise, SCRATCH 
SYS must be run on all the packs containing the real temporary data sets. 

For TSO system-named temporaries, SCRATCH SYS is the only good way 
to deallocate real temporaries, since restart is not supported. 


With VIO, deallocation of temporaries requires only a re-IPL that specifies 
CVIO (Clear VIO) at warm start or at cold start. All auxiliary slots containing 
VIO data set pages will be freed regardless of whether or not the volumes on 
which they reside are mounted. 


e VIO is physical device independent. That is, under control of the paging 
I/O algorithms, the physical device chosen to contain the data set has no 
relation to the device being simulated. The device chosen will be the best 
one for the system at the time the I/O is required. No matter how device- 
dependent the user’s code is, VIO will remain device independent. 
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VIO Performance (continued) 
Disadvantages 
These appear to be the disadvantages of VIO: 


e VIO for large data sets (particularly if not in update processing) may be less 
efficient than conventional I/O. Pages from large VIO data sets will be readily 
stolen and the data forced out to paging space. 


@ VIO is less efficient than conventional I/O for physical data transfer, if the 
simulated block size is large, ie., fewer than 9 blocks per track on a 3330. 
For example, on a 3330 VIO uses slightly fewer instructions to read or write 
a full track than does EXCP at 9 blocks per track, but with quartertrack 
blocking VIO requires approximately twice as many CPU instructions per 
track as does EXCP. 


e@ The system data set SYS1 STGINDEX saves the page data set status of 
jobs that are eligible for automatic checkpoint or step restart. If 
SYS1.STGINDEX fills up, the job step can not be restarted. 


VIO Performance Considerations 
To optimize VIO performance, try to make use of these performance considerations: 


e VIO is most efficient for.small data sets used for update processing. Such data 
sets may refer to data pages frequently enough to allow page reclaim. Page 
reclaim consists of the reuse of a page of data in real storage before it can be 
written out to paging space. You can measure the relative success of page 
reclaims by running MF/1, and noting the number of VIO page reclaims listed 
in the Paging Activity report. 


e@ Allocate VIO data sets by cylinder to minimize overhead. VIO simulates the 
physical device by software coding. I/O requests are checked for validity 
against the data set extents. For data sets allocated by cylinders, a check is 
made for SEEK or SEEK CYLINDER channel command codes. However, 
for block allocation (the default) or for track allocation, all channel command 
codes that can cause a reference to any track other than the current must be 
validity checked which causes additional overhead. This includes SEEK, 

SEEK CYLINDER, SEEK HEAD, all multi-track commands, overflow READS, 
etc. 


e Use VIO for blocks of data 1200 bytes or less, and IOS for blocks of 3200 
bytes or more. Measurements have shown that VIO uses fewer CPU 
instructions to process a 1200 byte (or less) block of data than IOS; IOS uses 
fewer instructions than VIO to process a 3200 byte (or more) block of data. 
For the range of blocksizes between 1200 and 3200, VIO should be used if 
the system has light paging activity. 
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e It’s best to choose a block size whose multiple (plus block headers and 
window control record) almost completely fill the pages that comprise the 
window. The VIO “window” that is written out to paging space is always 
equal to the used portion of the track size (data plus track overhead) rounded 
up to the next multiple of 4K. Although the window, when full, is always 
four pages for a 3330, the amount of data transferred depends on the number 
of bytes of the data on the simulated track. Avoid a block size that requires 
an additional page for the window without significantly increasing the data 
being transferred. For example, a block size of 2035 uses a three-page window 
to transfer 12,210 bytes of useful data, plus 8 bytes for each block header 
and 30 bytes for a window control record, at six blocks per track.(This is a 
total of 12,288 bytes.) In contrast, a block size of 2036 bytes uses a four- 
page window to transfer 12,216 bytes of useful data, plus 8-byte block 
headers and a 30-byte window control record, for a total of 12,294 bytes, 
also at six blocks per track. However, the 2036-byte block size needs an 
extra page in the window, consisting of 4090 wasted bytes, to transfer 6 
additional bytes of useful data. 


e VIO data sets ought not be allocated and held for long time sharing sessions. 
Since temporary data sets are usually freed only at the end of a TSO session, 
the total paging space in use can become excessive. The installation can 
control the total allocated VIO space per TSO session, possibly by means of 
a DAIR exit. 


e Consider chained scheduling for non-VIO data sets. The use of OPTCD=C, 
together with an increase in the number of buffers (for example, 
BUFNO=6), has been found to significantly reduce system instructions in 
some batch environments. 


How to Specify VIO Data Sets 


The following are the requirements for specifying VIO data sets: 


e The UNITNAME macro at sysgen must specify VIO=YES. Both generic and 
esoteric names are accepted. With an esoteric name, the first unit in the list 
must be a direct access device. A generic name must be DASD and should not 
specify a unit list. 


e@ The data set must be specified or defaulted as temporary 
(NEW,DELETE or NEW,PASS). 


e@ The volume request must be non-specific (i-e., no volume serial number). 


e@ The total SPACE parameter — primary and used secondary — can not exceed 
one volume on the device being simulated. The primary space specification 
will be accepted up to a value of one volume on the simulated device. The 
default space value is (1000,(10,50)). 


e The data set should have no dsname or should be specified by &name. 
e VIO cannot be used for VSAM or ISAM data sets. 


e@ The unit count subparameter of the DD UNIT parameter is ignored. 
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Questions and Answers 


The following questions are those that customers have asked regarding VIO. 


Q: 


What is the effect of VIO usage when going from a paging load of light 
to heavy? Is there a mechanism or procedure to offset any negative effect? 


The effect consists of possibly increased I/O and CPU overhead. Both 
factors slow VIO performance. However, CPU overhead may not increase 
proportionately with increased paging, since the Auxiliary Storage Manager 
may be able to chain more pages together for I/O. One answer would be to 
provide more paging devices, faster paging devices, and different channel 
paths. Another solution would be to obtain more real storage. 


Are there any advantages in simulating a 2314 for VIO data sets if the 


paging device is a 3330 or 2305, even though no 2314s may actually be 
in the system? 


Yes, if you have code that depends on the device being a 2314. Be sure 
that an IODEVICE macro at sysgen specified a 2314, at a unique address, 
even though there are no physical 2314s on the system. 


Does VIO fill the window for an input data set as an anticipatory paging 
operation? 


No. The window is filled only as the result of input requests. 


The track capacity of a simulated 3330 for VIO requires a four-page 
window. However, if I block my data 1680 bytes per block, the seven 
blocks will fit in the first three pages of the window. Are all four pages 
paged out? 


No. Only those pages that have data are paged out. 
Can a job that runs ADDRSPC=REAL use VIO? 


Yes. 
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Q: 


If paging error occurs with a VIO data set, does a user SYNAD exit get 
control? 


No. (For discussion of paging error handling, see the Questions and 
Answers section in the topic “Guidelines for the Use of Paging Data Sets”’.) 


Is there a limit to the size of a VIO data set? If so, how is it specified? 


The size of a VIO data set can be limited via the JCL SPACE parameter in 
the same manner as with non-VIO data sets. The maximum size of a VIO 
data set is one volume of the device type being simulated. 


Do you have one window per active VIO data set or one per address space? 


One per data set. This applies no matter how many DCBs the user may have 
open to the data set. 


What happens when the user buffer size is greater than VIO window Size? 


A buffer size (block size) that is larger than the window size can be valid 
only if the track overflow feature is being simulated, since the window size 
is equal to one track of the device being simulated, rounded up to the next 
4K. If track overflow is not being simulated, an error indication (blocksize 
larger than physical track size) will be returned. 


Can UNITNAME macro at sysgen contain VIO=YES for a device not 
installed at the installation? 


A device can be simulated that is specified at sysgen, via both the 
UNITNAMEand IODEVICE macros, but which is not physically online 
to the system. 


Does PCI work with VIO? 


Yes. Existing programs that use the PCI feature will work with VIO. 
However, the user should understand that the I/O is being simulated, and 
the PCI interrupts and associated processing have no relation to the real 
I/O to the paging data sets. 


Is the window block-paged or individually paged? 


The window is block paged on output but is individually paged on input, 
via a page fault. 
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Device Allocation Performance J 


This topic discusses how an installation can improve performance through the 
allocation of devices, data sets, and volumes. The first section describes the order 
in which allocation requests are serviced. The remainder of the topic provides 
guidelines for improving allocation response. 


Note: For SRM influences on Device Allocation, see “Device Allocation” in the 
chapter “The System Resources Manager”. For Auxiliary Storage Manager 
influences on the selection of paging devices, see“ Part 2.1: Auxiliary Storage 
Management Initialization. ” 


The Order in Which Allocation Requests Are Serviced 


The order in which allocation requests are handled by the system affects the 
processing time and the degree of serialization of particular allocations. To reduce 
serialization, allocate your data sets, volumes, and devices from the categories high 
on the following list, if possible. As you move down the list, the degree of 
serialization and the processing time increase. 


1. VIO data sets, JES2 or JES3 data sets, and dummy data sets. 


2. Permanently resident or reserved direct-access volumes (see the VATLSTxx 
description in the Initialization chapter for information on the specification 
of these volumes). 


3. Teleprocessing devices; and generic device types as specified in the device J 
precedence list, except devices which hold permanently resident or reserved 
DASD volumes. (See the guideline later in this topic on the use of the 
DEVPREF keyword of the SCHEDULR macro to specify the device 
precedence list.) 


4. Unmounted nonspecific direct access volumes. These requests cause 
serialization with other allocations until the operator mounts the volumes. 


5. Offline devices and devices allocated to another job. These requests require 
operator interaction. 
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Guidelines for Improving Allocation Response 


The following suggestions should help your installation to make best use of the 
redesigned Device Allocation routines: 


e Within the limit of page space availability, encourage the use of VIO data 
sets. (For further information, see the topic entitled “VIO Performance”’.) 


@ Set up a sufficient number of permanently resident and reserved DASD 
volumes on line, to avoid contention for a few volumes of these types. 
You can check for contention by running MF/1 to obtain device activity 
reports. The volumes should be spread across channels so that the System 
Resource Manager can balance the channel load. 


e@ Use the UNITNAME sysgen macro to define separate esoteric subgroups 
within major generic device types, so that different subsets of users can 
request separate subgroups of devices. The purpose is to minimize contention 
for the same devices among the various subsets of users. For example, an 
installation whose batch and time sharing users request allocation of 3330's 
could separate the two types of user requests as follows: 


UNITNAME UNIT=(330,4) ,NAME=SYSBATCH 
UNITNAME UNIT=(334,4) ,NAME=SYSTSO 


The effect of this specification is that allocations to SYSBATCH serialize only 
requests for units 330—333, instead of the entire 3330 generic. Similarly, 
allocations to SYSTSO serialize only requests for units 334—337. 


e Use the DEVPREF keyword of the SCHEDULR sysgen macro to minimize 
contention for the fastest devices. The DEVPREF keyword sets up the device 
preference table. The table determines the order in which device types will be 
selected by Allocation if a request is eligible for more than one device type 
(e.g., UNIT=SYSDA). If the keyword is not specified, the default device 
preference table lists the fastest generics first. If such specification causes 
heavy contention for the fastest eligible devices, you can specify the 
DEVPREF list so that generics with many devices (and many channels) are 
listed first and are therefore given preference. As as secondary consideration, 
the increased number of preferred units and channels will give the System 
Resource Manager a large selectionfor its choices. 


e@ Keep all operable devices online if possible. (This is old advice and does not 
depend on the redesign of Device Allocation.) 


e Try to avoid the use of specific unit address (e.g., UNIT=253) in DD 
statements for volumes that are neither permanently resident nor reserved. 
A specification of specific unit address serializes the request on the entire 
device type. For example, if unit 253 is a 3330, a specific unit request 
(UNIT=253) will be serialized with other requests for any 3330. Instead 
of using specific unit address, use subsets of the generic device type, as 
suggested earlier in this topic. 
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@ Resolve the question whether the operator should respond HOLD or 
NOHOLD when a job must wait for other jobs to free devices or volumes, 
and a message is issued to the operator. The criteria for resolving the 
question are: 


HOLD This means that the job should wait while holding devices 
and volumes already allocated to the job. Select this option 
if the needed resources are constantly being freed, and 
allocation requests for other jobs will probably not be held 
up by the requests made for this job. This job can hold up 
other requests in either of two ways: it has already allocated 
units needed for another job, or its allocation requests are 
serialized on devices it is waiting for. 


NOHOLD This means that the job waits without holding devices and 
volumes already allocated to the job. Select this option if 
the needed resources may not be freed for some time, and 
allocation requests for this job are likely to hold up requests 
issued for other jobs. 


Note: Requests for dynamic allocation are not held up by requests waiting 
for batch allocation, even though the jobs awaiting batch allocation are 
holding resources. 


e Free data sets, volumes, or devices before the end of a job step or TSO 
session, if possible. The freed resources can then be used for other jobs or J 
sessions. You can free the resource when a data set is closed, by specifying 
FREE=CLOSE on the associated DD statement. (This option is a new 
facility in MVS.) Note that when subsequent steps of a job require the same 
data set, the resource must be reallocated prior to being reaccessed (or else 
the OPEN fails). Use discretion when freeing the resources, however, because 
once a resource is freed, its continuing availability cannot be guaranteed. 


e Invoke Dynamic Allocation from a batch job by means of a new application 
of SVC 99. (The details are described in OS/VS2 System Programming 
Library: Job Management.) The advantage is that the batch 
job allocates the resource only when it is needed, and frees it as soon as 
it is not needed. (FREE=CLOSE can also free the resource, if it is specified 
on a DD statement.) Resources are thus more readily available to other 
requesting jobs. A disadvantage is that the batch job must handle a return 
code if the requested resource is not available. (With conventional allocation 
via DD statements, the system would cause the job to wait for the 
requested resource(s) to become available.) Note, however, that an 
authorized program need not handle a return code if a requested resource is 
not available. The authorized program can request a “wait for the resource” 
when it invokes Dynamic Allocation. (Unfortunately, there is no deadlock 
detection in this case.) 
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e Premount all private volumes, including private catalogs, before running the 
jobs that request these volumes. (This is another piece of old advice.) Note, 
however, that AVR (Automatic Volume Recognition) is no longer optional. 


TSO Allocation Suggestions 


The following suggestions should improve TSO allocations during TSO sessions 
although they may extend log-on times: 


e DD statements that a user wants in all his TSO sessions should be placed in 
a LOGON procedure. This technique has these advantages: 


— 


.Allows volumes to be mounted. 


2. Provides recovery from an offline device condition. Messages tell the 
operator to VARY the device online. 


3. Saves repeated allocation and freeing of the same data set by successive 
commands in the same TSO session. 


@ The DYNAMNBR parameter value in the EXEC statement should be 
carefully chosen. The value should be large enough so that it is not readily 
exceeded by dynamic allocation requests. Note that the maximum nuinber 
of concurrently allocated resources for any TSO session is 1635. 


The topic “How the SRM Allocation Algorithm Affects I/O Load Adjusting”, 
formerly here, is now rendered obsolete by the SRM redesign. 
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In practice, it is not always possible to restrict a job’s I/O dependencies to a J 
single channel. However, any reduction in the job’s I/O dependencies will improve 
the job as a candidate for correcting I/O load imbalances. Accordingly, the SRM 
Device Allocation algorithm selects channels with the objective of minimizing a 
job’s logical channel dependencies. 


The same strategy should be followed by job submitters. This is particularly 
important in the case of jobs which do a considerable amount of I/O over a 
sustained period of time. It is of course important that not all jobs choose their 
data sets through the same logical channel(s). This suggests some understanding 
between the installation and its heavy I/O users, supplemented by the use 
of job classes. The job classes must ensure a good distribution of jobs with 
different logical channel dependencies. 


An important secondary benefit is realized from this allocation strategy. When 
a particular channel has an uncorrectable overload, every address space which 
depends on this channel has its processing slowed by the slow channel response. 
If many of the executing address spaces are slowed by such a dependency, the 
result is a significant drop in throughput, accompanied by a drop in the utilization 
of other system resources. This drop occurs because many address spaces spend 
much time waiting on the overloaded channel. If, however, some jobs do not 
depend on the overloaded channel, they will not be slowed by the overload, and 
they will be able to take advantage of the lowered demand for other resources. 
Consequently they will run faster than would normally be the case. 


Questions and Answers J 
The following Allocation question has been asked by customers: 
Q: The Device Allocation algorithm in the System Resources Manager tries to 
minimize the number of logical channels used by a batch job or TSO 


session. What happens if a job’s execution time depends on channel 
separation? 


A: Use specific unit allocation or an esoteric name eligible to a single 
channel. 
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Note: These guidelines pertain to VSAM catalogs only, not to OS CVOLs. For 
information on OS CVOL usage under the VSAM master catalog, refer to OS/VS2 
Using OS Catalog Management With the Master Catalog: CVOL Processor. 
Additional catalog information can be found in the OS/VS Virtual Storage 
Access Method (VSAM) Programmer’s Guide. Additional tuning aids are described 
in “Chapter 3: Catalog Conversion” of the OS/VS2 Conversion Notebook. 


The performance of VSAM catalogs can be improved by adhering to the 
following guidelines: 


e@ Choose a primary space value large enough to hold the data to be cataloged, 
but do not grossly overspecify. Excessive unused space wastes seek time. 
Secondary space allocation should however be specified to avoid 
reorganization of the catalog at inconvenient times if the primary space 
becomes full. Try to arrive at a value for primary space such that secondary 
space is used only for occasional overflow. A formula is available in 
OS/VS2 System Programming Library: Storage Estimates for the calculation. 


e@ Specify a sufficiently large BUFFERSPACE value in the DEFINE 
MASTERCATALOG and DEFINE USERCATALOG commands* for each 
shared VSAM catalog in order to maximize the number of concurrent searches 
(LOCATEs) of the VSAM master catalog and each job-shared VSAM user 
catalog. If, however, a VSAM user catalog is not shared across jobs, there is 
no need to provide the capability for concurrent searches. 


The buffer (defined by BUFFERSPACE) is used for the reading of the 
index and data portions of the catalog. The minimum or defaulted specifica- 
tion of 3K bytes of pageable virtual storage allows two concurrent searches of 
the catalog. Each additional 1K bytes permits one more concurrent search, 
up to a maximum of seven concurrent searches ata BUFFERSPACE value of 
8K. (Thus, a BUFFERSPACE value of 4K would allow three concurrent 
searches.) A maximum of one catalog search per address space at one time is 
possible, except if there is user subtasking, in which case more than one 
concurrent catalog search per address space is possible. 


Note: The BUFFERSPACE value should be specified as or defaulted to the 
minimum (3K) for a VSAM user catalog that is not shared across jobs. 


*The DEFINE commands are described in OS/VS2 Access Method Services. 
The STEPCAT or JOBCAT DD statement for a VSAM user catalog can also 
specify buffer size, via the BUFSP subparameter of the AMP parameter. (See 
OS/VS2 JCL.) If both the DEFINE command and JCL specify buffer size, the 
larger specification overrides the smaller. In other words, the JCL specification 
can increase the buffer size but not decrease it. 
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e Although a large BUFFERSPACE value is good for shared VSAM user vast 
catalogs, don’t overspecify. There are three reasons: 


1. A BUFFERSPACE value of more than 8K is automatically reduced to 8K 
without increasing the number of concurrent catalog searches beyond the 
maximum of seven. 


2. Each increase in BUFFERSPACE value beyond the minimum (3K) requires 
additional fixed storage, at the rate of 224 bytes of fixed storage for each 
1K bytes of increased specification. Thus, a BUFFERSPACE value of 8K 
would require 1568K bytes (448 + 5 x 224) of fixed storage. 


3. Concurrent searches can occur only when the catalog is being referenced 
(for example, by Allocation or Open). Concurrent searches will result 
only to the extent that such referencing occurs simultaneously in two or 
more address spaces. If a catalog is not shared, there will be no 
concurrent searches. 


e I/O operations to a catalog are performed by use of a control block called a 
Request Parameter List (RPL). The number of RPLs determinés the 
maximum number of concurrent Locates that can be done. When all the 
RPLs are in use, the next Locate will cause an exclusive enqueue on the RPL 
resource. The dequeue will not be done until this Locate completes, thus 
allowing only one Locate at this time. The number of RPLs is determined by 
the BUFFERSPACE value specified on the DEFINE MASTERCATALOG or J 
DEFINE USERCATALOG command, or as altered by the ALTER CATALOG 
command. The larger the BUFFERSPACE size, the greater the number of 
RPLs. Therefore, in systems where storage is not a critical resource, the 
BUFFERSPACE parameter value should be increased to 8K for more efficient 
Locate performance. In systems where storage is at a premium, the default 
value of 3072 bytes is recommended. 


@ The installation may wish to use the same VSAM catalog for jobs that 
normally run concurrently. (Note that although concurrent searches can be 
shared, updates always require exclusive access to the catalog.) You may 
connect concurrently running jobs to the same VSAM user catalog (e.g., 
ten jobs to one catalog) in order to optimize the use of fixed storage and 
reduce execution time. One way this can be done is by specifying the same 
catalog name in the JOBCAT DD or STEPCAT DD statements for the con- 
current jobs. In this case, specify a relatively large BUFFERSPACE value, up 
to 8K. The disadvantage of catalog sharing, however, is that the jobs will 
contend for the use of the shared catalog. 
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e@ Avoid a lot of user catalogs in systems where storage is a critical resource. 
Improved response times have been observed in a two megabyte environment 
when the number of user catalogs has been reduced from six to two. Fewer 
user catalogs will require less fixed storage, and can improve response times. 


@ You may improve catalog search speed by placing all data sets of a job or 
step, if possible, in the same VSAM user catalog. The catalog should preferably 
be identified by a JOBCAT or STEPCAT DD statement. Such identification is 
useful because the catalog search begins with catalogs identified by JOBCAT 
or STEPCAT DD statements. However, even without such identification some 
search time can be saved, if data sets used in job steps or time sharing sessions 
have the same highest level dsname qualifier. In this case, the VSAM master 
catalog will be searched the first time that a data set must be found. 
Subsequent searches will bypass the master catalog and go directly to the 
appropriate user catalog. 
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Questions and Answers 


The following questions on the VSAM catalog have been asked by customers. 


Q: 


Al: 


A2: 


Will connected CVOLs and STEPCAT or JOBCAT catalogs be mounted at 
interpreter time? 


In general, no. The catalogs are mounted at the time they are allocated. 
How Serious is the loss of the VSAM master catalog to MVS? 


If there are no VSAM data sets represented in the master catalog, other 
than paging, swapping, the catalog itself, and SYS1. STGINDEX, then 
the impact is similar to losing an OS master catalog. If VSAM data sets 
exist, then VSAM recovery techniques and considerations apply. (See 
OS/VS Virtual Storage Access Method (VSAM) Programmer’s Guide. ) 
The VSAM master catalog, as well as paging data sets, swapping data 
sets, and SYS1.STGINDEX, must be rebuilt on an MVS system. Non- 
VSAM data sets still have VTOC entries and can be recataloged. 


If the VSAM master catalog can’t be opened, or if certain system data 
sets can’t be found (via LOCATE macros), the system can’t be initialized. 
If there are catalog problems after system initialization, the impact to the 
system depends on the degree of reliance on the catalog and on the fraction 
of the catalog that is unusable. (It is unlikely that the entire master 
catalog will become unusable at the same time.) 


Under what circumstances should an installation convert its OS CVOLs to 
VSAM user catalogs? 


Use CVOL support and do not immediately convert CVOLs to VSAM user 
catalogs, if you have varied systems, some under MVT and one or more 
under MVS, and you wish to use your data on both systems. As 
applications are moved to the MVS system(s), gradually move the 

data sets to VSAM user catalogs for improved performance and easier 
maintenance™. 


Convert OS CVOLs to VSAM user catalogs, via the CONVERTCAT utility, 
for improved performance and easier maintenance™*, if you have one or 
more MVS systems that have users with CVOLs, and there are 

no longer any MVT systems at your installation. Such conversion is 
desirable even though the VSAM master catalog could continue to point 

to the CVOLs. 





"Utilities IEHLIST and IEHPROGM do not have full function for OS CVOLs under 


MVS. 
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How SMF Can Supplement MF/1 


MF/1 records or reports can be used to identify intervals during which the 
utilization of certain system resources has been unusual. MF/1 data includes infor- 
mation on CPU, the paging subsystem, channels and devices, pageable real storage, 
and workload activity. SMF can be used concurrently to list information that 
describes the workload processed during the same time interval. There may be a 
correlation between unusual resource utilization and the processing of particular 
batch jobs or time sharing sessions. 


MF/1 can be used to determine the average system workload level over a 
relatively long period of time. SMF can be used during the same period to identify 
the exceptional jobs, jobsteps, and TSO sessions that received service rates 
significantly different from those defined in the IPS at that workload level. 
Exceptional jobs or TSO sessions are those that either receive unusual service or 
place exceptional demands on system resources. System resources consist of the 
paging subsystem, the CPU, channels, devices, real storage, etc. 


Exceptional jobs or TSO sessions can be identified by summarizing SMF 
statistics*. When these jobs and sessions have been identified, the installation can 
investigate the reasons for the exceptional service or demands, and then make 
changes. For example, a change to the blocking factor may turn a heavy 
]/O-demand job into an average I/O-demand job receiving average service. 


MF/1 and SMF together can be used for at least the following purposes: 


e Comparison of paging rates for a problem program and the system 
e@ Comparison of I/O activity for a problem program and the system 
e Comparison of problem program service versus total service 

e Determining changes to the system configuration 


Comparison of Paging Rates for a Problem Program and the System 


This program-versus-system comparison can suggest paging problems within the 
problem program. The program’s paging rate is indicated by SMF record types 4 and 
34 (see OS/VS System Management Facilities (SMF)). The installation can 

calculate paging rate for the jobstep from the formula: 


Paging rate = jobstep pages in and out / CPU time for the jobstep. 


A similar rate for the system can be determined during the same time interval from 
SMF record types 70 and 71. Type 70 contains the length of the measurement 
interval and the CPU wait time during the interval. Type 71 contains paging data, 
including page-ins and page-outs, and the interval length. The system calculation 

is basically the same as the job step calculation stated above, except that CPU time 
must first be determined by subtracting CPU wait time from the total time interval. 


*The Statistics Gathering Program (SGP) is available as a data reduction tool for 
SMF data. The program is distributed as field-released program No. 5798-AYY. 
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Comparison of I/O Activity for a Problem Program and the System 


This program-versus-system comparison on first observation seems to be one of 
apples to oranges, since MF/1 counts SIOs, and SMF counts EXCPs (which include 
SVC0’s, PCI interrupts, channel-end interrupts, and abnormal-end interrupts). It is 
possible, however, to obtain a ratio of EXCPs to SIOs by using the sum of the 
jobstep EXCPs from SMF and the sum of the SIO counts from MF/1 for the same 
measurement period. When you have established this I/O ratio, you may be able to 
detect those jobsteps whose I/O operations seem excessive. Appropriate corrective 
action can then be taken. 


Comparison of Problem Program Service and Total Service 


The installation can compare the service given to particular performance groups 
versus total system service by examining SMF record types 5 and 35, and compar- 
ing their data with that in record type 72 which is produced by MF/1. Record 

types 5 and 35 contain the number of service units required by a job or TSO session. 
Record type 72 gives the total service provided for all jobs and TSO sessions. By 
comparing the data from these two sources, the installation can determine 

whether service is being distributed according to the goals of the installation. 


Determining Changes to the System Configuration 


configuration while the system is running. The data is contained in record types 0, 
8,9, 10,11, 22, 70, 73, and 74. This information is important during analysis of 
MF/1 data, since it can explain significant changes in the MF/1 output. Explanation 
of these changes might otherwise be left to speculation or to an exhaustive study of 
the operator’s console output. 


SMF provides information on the system configuration at IPL and changes to that ) 
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System components issue the SYSEVENT macro to inform the System Resource 
Manager (SRM) that the status of an address space or a system resource has changed. 
(The SYSEVENT is somewhat analogous to the TSEVENT macro in MVT.) The 
SRM is informed of critical changes to the availability of real storage frames, auxi- 
liary storage slots, and SQA virtual space. In addition, the SYSEVENT may request 
that the SRM perform a service. For example, the REQSERVC sysevent (code 
X26’) is issued to request that the SRM obtain service data related to a particular 
address space. (See Figure 5-3 at the end of this topic for descriptions of the various 
SYSEVENT codes.) 


The installation can monitor SYSEVENT activity during a selected time interval 
by starting GTF with the SRM option. The SRM option causes GTF to write a trace 
record each time a SYSEVENT macro is issued. (Information on how to use GTF is 
available in OS/VS2 System Programming Library: Service Aids.) The SYSEVENT 
trace record contains a time stamp, an address space control block (ASCB) address, 
a CPU identification (CPUID), a jobname (if applicable, and if comprehensive trace 
records have been requested), and contents of regs 0, 1, and 15 which contain 
information peculiar to the particular SYSEVENT. The information includes the 
SYSEVENT code that indicates why the SRM was invoked. (See Figure 5-2 for the 
format of the SRM trace record.) 





record format event 
Field identifier identifier identifier ASCB R15 RO R1 
Name length reserved (AID) (FID) timestamp (EID) addr CPUID jobname_ contents contents contents 

X'FF’ X‘04' X'4001' (See 

(See (See (See note 4) 

note 1) note 2) note 3) 
Length 2 2 1 1 8 2 4 2 8 4 4 4 
Hex 
Offset 0 02 04 05 06 OE 10 14 16 1E 22 26 
Notes: 


1. The record identifier (AID) in GTF records is a one-byte 
hexadecimal number that identifies the record as a trace 
record or a control record. 


2. The format identifier (FID) in GTF records is a one-byte 
hexadecimal number that is used to determine the name 
of the AMDPRDMP EDIT module that will format the 
record. 


3. The event identifier (EID) in GTF trace records is a two-byte 
hexadecimal number that defines the event that caused the 
record to be built. The EID is in the form cddd where c is the 
event class (0O-F) and ddd is the |D of the event within the class. 


4. Jobname appears only in the comprehensive trace record. 
Comprehensive format must be requested when GTF is 
started. 





Figure 5-2, SRM Trace Record Format 
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The installation should reduce the trace data to determine the utilization of 2 
system resources and the service given to particular jobs or TSO sessions. The 
reduced data can supplement that obtained from MF/1 and SMF (see the perfor- 
mance topic “How SMF Can Supplement MF/1”’). For example, the trace data can 
indicate when shortages in paging space occur. This information can be used with 
SMF data to learn the identify of jobs and TSO sessions active at the time of the 
shortage. Possible corrective action may include the addition of more paging space, 
or external scheduling at the installation to prevent all the heavy paging jobs 
(possibly VIO users) from running at the same time. 


The sysevent data can be used to analyze the effect of the system running with 
insufficient SQA virtual storage. Distributions can be produced which identify the 
frequency and durations of the shortage periods. These intervals can be correlated 
with MF/1 data to determine how the SQA shortage affects CPU utilization, channel 
utilization, and service unit utilization. If the shortage time is excessive or if it 
causes a significant degradation of performance, the installation can make more 
space available for SQA virtual storage. 


Similarly, the sysevent data can be used to analyze the effect of the system 
running with a shortage of available page frames, i.e., in an AVQLOW* environment. 
If the shortage time is excessive or if it impacts performance, the installation may 
wish to modify the Real Storage Manager (RSM) constants that define the shortage. 


A sysevent trace tape can be sorted by address space ID (ASID), sysevent type, 
or by time of occurrence, etc. The sort yields a sequence of tabulated records for 
each job or TSO session. The time difference between the individual printed records Jd 
is the time between significant stages of a job or TSO session. The stages include: 
such items as address space creation, job selection, (START, MOUNT, or LOGON 
issued), initiator attaching a task, initiator detaching a task, and job termination. 
The sequence also contains a record for each time the address space is swapped into 
or out of real storage. For a TSO session, the sequence contains a record of each 
time the address space enters wait state and each time it becomes ready. 


*SYSEVENT X‘17’ 
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Through appropriate reduction of the data, the installation can obtain some 
meaningful time distributions. Some examples are: 


time needed to swap an address space in 
time needed to swap an address space out 
time address spaces spend in real storage 
time address spaces spend out of real storage 
user think time 

system response rate 

transaction arrival rate 

transaction processing rates 

job processing rates 

TSO session durations 


Information is also provided in the trace which identifies the names of time 
sharing commands and subcommands (see sysevent code 00 in Figure 5-3), This 
information should help the installation to produce time distributions for the 
individual TSO commands and subcommands. 


Figure 5-3 describes the meaning and input information (register contents) for 


each sysevent type. 


Figures 5-4 through 5-8 show sample printouts of a data-reduced sysevent trace. 
Note that unusual data are circled and annotated. 





Sysevent Code: 
Mnemonic: 


Meaning of Mnemonic: 


Circumstances: 


Inputs: 


Outputs: 


00 
TSEVENT 00 (PPMODE) 


A time sharing command, or a subcommand of EDIT or 
TEST, is to be executed. 


The TSO Terminal Monitor Program or the EDIT/TEST 
command processor issues this sysevent when the command 
or subcommand is about to be executed. It causes no action 
on the part of the SRM. 


Reg 0, bytes O—3: ASID 

Reg 1, bytes O—3: Contains the first four characters of the 
cOmmand or subcommand name. 

Reg 15: Contains the last four characters of the command 
or subcommand name. 


None 





Figure 5-3, Descriptions of SYSEVENT Codes (Part 1 of 24) 
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Sysevent Code: 01 

Mnemonic: TIMEREXP 

Meaning of Mnemonic: SRM time interval expired. 

Purpose: Assures that the SRM will gain control at least once within a 


predetermined real time interval. 


Circumstances: The timer routines have recognized that the SRM time 
interval has just popped (elapsed), or TOD clock initialization 
has occurred. At the time the sysevent is issued, the SRM’s 
timer queue element has been removed from the timer Queue. 


Inputs: Reg O, byte 3: Sysevent code 
Reg 1, byte 3: Contains X’01’ if entry is from system TOD 
clock initialization. Contains X‘'00’ otherwise. 





Outputs: None. 

Sysevent code: 02 

Mnemonic: TERMWAIT 

Meaning of Mnemonic: Terminal wait. 

Purpose: Indicates that a TSO Session has entered terminal wait. 
Circumstances: A TSO Session is in terminal wait after the issuance of a 


TGET or a TPUT. Receipt of the TERMWAIT sysevent 
indicates to the SRM that the current transaction for a TSO 
address space should be ended, provided that the address 
space has entered long wait status and is swappable. Note 
that the occurrence of this sysevent does not guarantee that 
the entire address space is in along wait status. This 
determination can only be made by Quiesce. 


Inputs: Reg O, bytes 0-1: ASID. 
Reg O, byte 3: Sysevent code. 
Reg 1, byte 0: contains X’00’ if input 
terminal wait; contains X’80’ if output terminal wait. 


Outputs: None. 





Figure 5-3. Descriptions of SYSEVENT Codes (Part 2 of 24) 
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Sysevent Code: 
Mnemonic: 
Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


03 


NIOWAIT 
Address space suspected of being in long wait. 


Indicates to SRM when an address space is suspected of 
having entered long wait. 


Some task in the address space just entered long wait. 
Occurrence of this sysevent does not guarantee that the 

entire address space is in a long wait status. This determination 
can be made only by Quiesce. The time spent by a swappable 
address space in long wait will not be considered part of the 
current transaction for that address space. 


Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code 


None. 


bl OO OOOO,Q,Q,Q,... EE 


Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


04 

USERRDY 

User ready. 

Indicates that a swapped out address space in a wait state or 
an address space for which Quiesce is running has at least one 


dispatchable unit (SRB) * which is ready to run. 


Something has occurred causing a dispatchable unit (SRB) 
to be scheduled to this address space. 


Reg O, bytes 0-1: ASID. 
Reg 0, byte 3: Sysevent code. 


None. 


“SRB means system resource block. 





Figure 5-3, Descriptions of SYSEVENT Codes (Part 3 of 24) 
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Sysevent Code 05: This code is not used. 

Sysevent Code: 06 

Mnemonic: MEMCREAT 

Meaning of Mnemonic: Address space create. 

Purpose: Indicates that a new address space is about to be created. 


Indicates the type of origin of the new address space (i.e., 
START, LOGON, MOUNT). Gives the SRM a chance to 
prohibit the creation of the address space. 


Circumstances: At the earliest point where the ASID is known and the space 
for the ASCB has been obtained. 


Inputs: Reg O, bytes 0-1: ASID. 
Reg O, byte 3: Sysevent code. 
Reg 1, byte 3: contains X‘01’ if START; X’02’ if LOGON; 
X'03’ if MOUNT. 


Outputs: Reg 1, byte 0: contains X‘00’ if acceptable to proceed; 
contains X’80’ if the address space should not be created 
because of a resource shortage as determined by the SRM. 





Sysevent Code: 07 

Mnemonic: MEMDEL 

Meaning of Mnemonic: Address space delete. 

Purpose: Indicates to the SRM the deletion of an address space, 


allowing the SRM to release resources assigned to that 
address space. 


Circumstances: Memory Delete is about to free the storage for the ASCB 
and unassign the ASID. 


Inputs: Reg O, bytes 0-1: ASID. 
Reg 0, byte 3: Sysevent code. 


Outputs: Reg 1, byte 3: contains X'04’ indicating that Memory Delete 
is to wait until posted by the SRM. 
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The Use of GTF to Track Sysevents (continued) 





i Sysevent code: 


Mnemonic: 
Meaning of Mnemonic: 


Purpose: 


Circumstances: 


08 

JOBSELCT 

Job selection. 

Indicates that an address space has started using system 
services on behalf of a new job, START or MOUNT 


command, or a TSO session. 


Whenever |EFSD161 handles one of the above. 





Inputs: Reg 0, bytes 0-1: ASID or zero, 
| Reg O, byte 2: performance group number. 
Reg 0, byte 3: Sysevent code. 
Reg 1, bytes 0-3: pointer to jobname or user ID. 
Outputs: None. 
Sysevent Code: 09 
Mnemonic: JOBTERM 


Meaning of Mnemonic: 


Purpose: 


% Circumstances: 


Inputs: 


Outputs: 


Job termination. 

Indicates that an address space has completed using system 
services on behalf of a job, START or MOUNT command, 
or a TSO session. 

Whenever |EFSD166 handles one of the above. 

Reg 0, bytes 0-1: ASID or zero. 

Reg 0, byte 3: Sysevent code. 


Reg 1, bytes 0-3: pointer to jobname or user ID. 


None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Purpose 


Circumstances: 


Inputs: 


Outputs: 


Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Purpose: 
Circumstances: 


Inputs: 


Outputs: 


OA 
INITATT 
Attach by initiator. 


Indicates an initiator has attached a task. Is related to a 
JOBSELCT sysevent (code 8). 


Whenever |EFSD263 attaches a task. 

Reg O, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Reg 1, byte 2: Performance Group Number of attached task, 
or 0. The presence of a O in this byte indicates that the 
address space will execute in a privileged status 

reserved primarily for system tasks, in which Service Rate will 


not be a swap consideration. 


Reg 1, byte 3: Dispatching priority to which this address 
space should be set. 


None. 


OB 

INITDET 

Detach by initiator. 

Indicates a task has been detached by an initiator. 
Whenever |EFSD263 detaches a task. 

Reg O, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Reg 1, byte 3: Dispatching priority to which this address 


space should be set. 


None. 
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The Use of GIF to Track Sysevents (continued) 





Sysevent Code: OC 

Mnemonic: QSCEST 

Meaning of Mnemonic: Quiesce started. 

Purpose: Permits an initial assessment of whether an address space, 


suspected of being in long wait, is in fact in long wait. Provides 
for the reversal of the Quiesce of an address space. 


Circumstances: The SRM has recently posted Quiesce. 


Inputs: Reg 0, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, byte 0: Contains X‘00’ if the address space is not in 
long wait; X’80’ if all tasks in the address space are in long 
wait. 


Outputs: Reg 1, byte 3: Contains X'00’ if RCT is to continue with 
Quiesce; contains X’08’ if the address space should be 
restored to its Original status. 





Sysevent Code: OD 

Mnemonic: QSCECMP 

Meaning of Mnemonic: Quiesce completed. 

Purpose: Permits a final assessment of whether the address space is to 


be swapped out. If between QSCEST (code 12) and 
QSCECMP, a USERRDY (code 4) has been received for the 
address space, Quiesce will be notified that the memory is 
not in true long wait status. 


Note: The swapped in interval is defined to end with this 


sysevent. 
Circumstances: RCT has completed quiesce processing for an address space. 
Inputs: Reg O, bytes 0-1: ASID or zero. 


Reg 0, byte 3: Sysevent code. 
Reg 1, byte 0: Contains X’00', if address space not in long 
wait; X‘80' if address space is in long wait. 


Outputs: Reg 1, byte 0: contains X’00’ if USERRDY (code 4) was 
just received; unchanged by SRM if no USERRDY 
received since QSCEST (code 12). 
Reg 1, byte 2: Contains swap reason code. 
Reg 1, byte 3: Contains X’00’ if the RCT is to schedule 
swap-out; X’0O8' if address space is to be restored. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 


OE this code is not used. 





Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Circumstances: 


Inputs: 


Outputs: 


OF 

SWOUTCMP 

Swap-out completed. 

Indicates that swap-out processing has completed. 


All 1/O needed to swap-out this address space has just 
completed. 


Reg O, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Reg 1, bytes 0-3: Address of a parameter list. 

The format is as follows: 

Word 1, bytes 0-1: The number of pages swapped-out. 
Word 1, bytes 2-3: The working set size (the number 
of pages to be swapped-in). 
Word 2, bytes 0-2: The number of pages freed by 
swap-out without performing 1/O. 
Word 2, byte 3: - Flag byte indicating: 


Bits O—6: Reserved 


Bit 7: O if address space is in long wait; 
1 if address space is waiting for an unfinished 
Real Storage Manager service. 


None. 


10 (hex). 
SWINSTAT 
Swap-in status. 


Swap-in processing for an address space that has just started, 
or just completed. 


Reg O, bytes 0-1: ASID or zero, 
Reg O, byte 3: SYSEVENT code. 
Reg 1, byte 3: 

01: Swap-in is starting. 

02: Swap-in is complete. 


None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 11 (hex) 

Mnemonic: SWINFL 

Meaning of Mnemonic: Swap-in failed 

Circumstances: Swap-in processing failed to obtain or initialize the LSQA and 


fixed pages for the specified address space. 


Inputs: Reg 0, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code 


Outputs: None. 
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Sysevent Code: 
Mnemonic: 


Meaning of Mnemonic: 


12 (hex) 


QSCEFL 


Quiesce failed. 





Purpose: Notifies the SRM that during an attempt to quiesce an 
address space the Quiesce function has failed. The address 
space has been restored when the sysevent is issued. 

Circumstances: Region Control Task failed to complete quiesce processing 
due to an abnormal situation. 

Inputs: Reg O, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Outputs: None. 

Sysevent Code: 13 (hex) 

Mnemonic: RSTORCMP 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


inputs: 


Outputs: 


Restore completed. 


Permits an assessment of whether an address space, suspected 
of having left long wait status, is in fact ready. 


Note: The swapped in interval is defined to begin with 
this sysevent. 


Region Control Task has completed restore processing for an 
address space. The circumstances giving rise to the restoring 

of an address space still in long wait ster from not knowing 
that the address space is waiting on more than one event. 


Reg 0, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Reg 1, byte 0: Contains X‘Q0’ if the address space is ready; 
contains X80’ if the address space is in long wait. 


None. 
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Sysevent Code: 14 (hex) 

Mnemonic: ENQHOLD 

Meaning of Mnemonic: ENQ contention occurred. 

Purpose: Informs the SRM of an address space responsible for 
contention. 

Circumstances: An address space is now being delayed because a resource is 


held. Contention between tasks in a single address space is 
not distinguished from contention between address spaces. 


Inputs: Reg 0, bytes 0-1: ASID of address space holding the resource. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Address of minor QCB for the resource. 





Outputs: None. 

Sysevent Code: 15 (hex) 

Mnemonic: ENORLSE 

Meaning of Mnemonic: ENQ contention reduced. 

Purpose: Informs the SRM of an address space which formerly was 


responsible for contention. 


Circumstances: Contention has disappeared because a resource has been 
released. 
Inputs: Reg O, bytes 0-1: ASID of address space holding the 


resource during contention. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Address of minor QCB for resource. 


Outputs: None. 
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Sysevent Code: 
Mnemonic: 


Meaning of Mnemonic: 


16 (hex) 
RSMCNSTS 


Real Storage Manager constants. 





Purpose: Supplies the SRM with the size of functioning real storage 
and the number of pages on the available frame queue, when 
the ‘‘available frame queue below limit’ sysevent (code X‘17’) 
is issued. 
Circumstances: Issued when a VARY Storage command is processed and 
when the system is initialized. 
inputs: Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-1: Number of pages of functioning real 
storage. 
Reg 1, bytes 2-3: Number of pages that are on the 
Available Frame Queue when the ‘‘available frame 
queue below limit’’ sysevent is issued. 
Outputs: None. 
Sysevent Code: 17 (hex) 
Mnemonic: AVQLOW 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


Available frame queue below limit. 


Notifies the SRM that the number of real pages on the 
available frame queue has dropped below predefined limits. 


Issued whenever allocation of a real page frame causes the 
number left on the available frame queue to drop below one 
of the predefined limits. 


Reg O, byte 3: Sysevent code. 

Reg 1, byte 3: X’01‘ if the number of rea! pages on the 
available frame queue has dropped below the limit. 
X'02’ if the number of real pages on the available frame 
queue has dropped to zero. X‘03' if a page fault occurs 
and there are no pages on the available frame queue. 
X’04’ if the ratio of fixed pages to total pages has 
increased above the allowable value. 


None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 18 (hex) 

Mnemonic: AVQOK 

Meaning of Mnemonic: Available frame queue above limit. 

Purpose: Notifies the SRM that the number of real pages on the 


available frame queue has risen above a predefined limit. 


Circumstances: Is issued whenever unallocation of areal page frame causes 
the number left on the available frame queue to rise above 
the predefined limit. This sysevent is issued only when the 
number of real pages rises above the predefined limit after 
the ‘‘available frame queue below limit’’ sysevent (code 17) 





was issued. 
Inputs: Reg O, byte 3: Sysevent code. 
Outputs: None. 
Sysevent Code: 19 (hex) 
Mnemonic: SQALOW 
Meaning of Mnemonic: Unallocated SQA below threshold. 
Purpose: Indicates that the amount of unallocated virtual SQA has 


dropped below one of two predefined thresholds. 


Circumstances: Virtual Storage Manager has just satisfied an SQA allocation 
request which resulted in the amount of unallocated SQA 
dropping below one of the two predefined thresholds. 


Inputs: Reg 0, byte 3: Sysevent code. 
Reg 1, byte 3: Contains X'01' if first (less serious) threshold 
is passed; X‘O2’ if second threshold is passed. 


Outputs: None 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 1A 

Mnemonic: SQAOK 

Meaning of Mnemonic: Unallocated SQA above threshold. 

Purpose: Indicates that the amount of unallocated SQA has risen above 


one of two predefined thresholds. 


Circumstances: Virtual Storage Manager has just handled an SQA 
unallocation request which resulted in the amount of 
unallocated SQA rising above one of the two predefined 
thresholds. 


inputs: Reg O, byte 3: Sysevent code. 
Reg 1, byte 3: Contains X‘01’ if first (less serious) threshold 
has passed; X’Q2’ if second threshold passed. 


Outputs: None. 





Sysevent Code: 1B This code is not used. 





Figure 5-3, Descriptions of SYSEVENT Codes (Part 13 of 24) 


Part 5: System Performance Factors 277 


The Use of GTF to Track Sysevents (continued) ) 





Sysevent Code: 1C 

Mnemonic: DEVALLOC 

Meaning of Mnemonic: Device allocation request. 

Purpose: Provides SRM with necessary data for making a device 


allocation decision where two or more candidates exist. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 


Reg 1, bytes 0-3: Address of a list of three full-word 
addresses, The first points to a list of candidate UCB 
addresses. The second points to a list of addresses of 
UCBs already allocated to the requesting jobstep. The 
third points to a two-word return area. 


The first word in the list of candidate UCBs contains a count 
of the number of candidates in the list. The first word of the 
list of addresses of already allocated UCBs contains a count 
of the number of addresses in the list. All input and output 
data areas must be fixed. 


Outputs: Reg 1, bytes 0-3: Contains the same address present at input. 


Return area 1st word: Contains the address of the candidate 
list entry which was selected. 


Reg 15, byte 3: Contains X’00’ if allocation selection was ) 
successfully made; X‘O8' if it was unsuccessful. 





Sysevent Code: 1D 

Mnemonic: CONFIGCH 

Meaning of Mnemonic: System configuration change. 

Purpose: Indicates that resources are to be removed from or added to 
the system. 

Circumstances: The system operator has issued a VARY (online or offline) 


command for a channel, path, or CPU. 
Inputs: Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Points to the SMF type 22 record that 


describes the configuration change. 


Outputs: None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 
Mnemonic: 
Meaning of Mnemonic: 


Purpose: 


Circumstances: 


1E 

VERIFYPG 

Verify performance group. 

To determine if the input Performance Group Number is 
currently ‘*known” to the SRM, and to indicate the default 


value if the input number is not ‘’known". 


LOGON or the Converter/Interpreter has received a 
Performance Group Number which needs verification. 





Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, byte 3: Performance Group Number. 

Outputs: Reg 1, byte 2: Contains 0 if the input number is valid. If the 
input number is not valid, it contains 1 if the ASID belongs 
to anon-TSO user, or 2 if the ASID belongs to a TSO user. 

Sysevent Code: 1F 

Mnemonic: RESETPG 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


Reset performance group. 


Resets the Performance Group Number associated with an 
ASID. 


The system operator has entered a RESET jobname, 
PERFORM=nn command. 


Reg O, bytes 0-1: ASID. 
Reg O, byte 3: Sysevent code. 
Reg 1, byte 3: New performance group number. 


Reg 1, byte 2: Contains X‘00’ if the RESET request was 
honored, X‘04’ if the new Performance Group Number is not 
valid, or X'08’ if the ASID is not currently assigned. 
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The Use of GTF to Track Sysevents (continued) ) 





Sysevent Code: 20 (hex) 

Mnemonic: NEWIPS 

Meaning of Mnemonic: Set new IPS. 

Purpose: Change the IPS currently used by the SRM. 
Circumstances: The system operator has entered a SET command with the 


IPS keyword. To synchronize the deletion of the old IPS, 

the SET command processor waits on an ECB which will be 
posted by the SRM only after al! references to the old IPS have 
been replaced. The SET command processor is responsible for 
obtaining the storage for the new IPS description, and for 
releasing the storage for the old IPS description, when the 
SRM has indicated that it will no longer be referenced. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Contains the address of the SRM Workload 
Manager specification table (WMST) that describes the 





new IPS. 
Outputs: Reg 1, bytes 0-3: Contains the address of the SRM Workload 
Manager specification table (WMST) that describes the 
old IPS. 
Sysevent Code: 21 (hex) 
J 
Mnemonic: ALTCPREC 
Meaning of Mnemonic: Alternate CPU recovery (ACR) 
Purpose: Notifies the SRM that one CPU has been removed from the 


configuration. 


Circumstances: As a result of some error, ACR has had to reconfigure one 
CPU out of the system. 


Inputs: Reg 0, byte 3: Sysevent code. 
Reg 1, bytes 0-3: CPU address of failed CPU. 


Outputs: None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 22 (hex) 

Mnemonic: TGETTPUT 

Meaning of Mnemonic: TGET/TPUT satisfied. 

Purpose: Indicates a change in the status of the current TSO transaction. 
Circumstances: TGET or TPUT completed. 

Inputs: Reg O, bytes 0-1: ASID or zero. 


Reg O, byte 3: Sysevent code. 
Reg 1, byte O: - Flag byte, as follows: 


bit 0: Contains 0 if TGET was satisfied; contains 1 if 
TPUT was satisfied. 


bit 1: (applies to TGET satisfied only.) Contains 0 if all 
the data in the TSO input message was transferred by the 
TGET; contains 1 if part of the data in the TSO input 
message was not yet transferred by this TGET, i.e., if at 
least one more TGET is required to obtain the rest of the 
data in the TSO input message. 


bits 2-7: reserved 





Outputs: None. 

Sysevent Code: 23 (hex) This Sysevent is not traced by GTF. 

Mnemonic: SYQSCST 

Meaning of Mnemonic: System Quiesce function started. 

Purpose: Indicates that task and |/O activity in the system are being 
quiesced. 

Circumstances: The system operator has issued the QUIESCE command. 


Before the SYQSCST sysevent is issued, all CPUs should have 
been placed under the control of the Quiesce function. 


Inputs: Reg 0, byte 3: Sysevent code. 


Outputs: None. 
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The Use of GTF to Track Sysevents (continued) J 
| Sysevent Code: 24 (hex) This Sysevent is not traced by GTF. 
Mnemonic: SYQSCCMP 
Meaning of Mnemonic: System Quiesce function completed. 
Purpose: Indicates that task and |/O activity in the system are being 
resumed. 
Circumstances: When the system has been quiesced, the operator has pushed 
the START button. 
inputs: Reg 0, byte 3: Sysevent code. 
Outputs: None. 
Sysevent Code: 25 (hex) 
| Mnemonic: SETDMN 
Meaning of Mnemonic: Set new constraint values for adomain. Changes the MPL 


constraint values for a specific domain. 


Circumstances: The operator has issued the SETDMN command. 

Inputs: Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Contains the address of a fixed data area. ) 
The data area is as follows: 


Byte 0: domain number. 

Byte 1: flags that indicate whether a corresponding 
value is passed in byte 2, 3 or 4, 

Byte 2: new minimum constraint value. 

Byte 3: new maximum constraint value. 

Byte 4: new domain weight. 


Outputs: Reg 15, byte 3: 
00 — Sysevent successful. 
04 — Domain is invalid. 
08 — Minimum constraint would exceed maximum 
constraint. 
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Sysevent Code: 
Mnemonic: 
Meaning of Mnemonic: 


Purpose: 


Circumstances: 


inputs: 


Outputs: 


26 (hex) 
REQSERVC 
Request for service data. 


Permits service-related data to be obtained for a given address 
space from the SRM. 


TSO TIME command will also use the REQSERVC sysevent 
to obtain service data. The REQSERVC sysevent must be 
issued prior to the JOBTERM sysevent (code 9), because the 
address space data is reset upon receipt of JOBTERM. 


The output area does not have to be fixed, and the issuer 
is not required to be authorized. 


Reg O, bytes 0-1: ASID or zero. 

Reg 0, byte 3: Sysevent code. 

Reg 1, bytes 0-3: Contains address of a 3-word area where 
the service data is to be stored. 


Service data supplied by SRM: 
In the case of a TSO address space,the 3-word area contains: 


Word 1 - Total service for the job. 

Word 2 - Total transaction active time. 

Word 3 - bytes 0-1: Performance group number last 
assigned to the address space. 
Bytes 2-3: Total number of transactions. 


In the case of a non-TSO address space, the 3-word area 
contains: 


Word 1 - Total service for the session. 
Word 2 - Total active time for all transactions. 
Word 3 - bytes 0-1: Performance group number last 
assigned to the address space. 
Bytes 2-3: Zeros. 
Reg 15, byte 3: Contains X'04' if data was lost due to 
accumulation control block error; X‘O0’ otherwise. 
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Sysevent Code: 


Mnemonic: 


Meaning of Mnemonic: 


Purpose: 


Circumstances: 


Inputs: 


Outputs: 


27 (hex) 
REQPGDAT 
Request by SMF for job paging data. 


Permits SMF to obtain paging data for a given address space 
from the SRM. 


Note: This sysevent is intended only for use by SMF 
because the related data fields in the OUSB and the OUXB 
are reset to zero on readouts. If requested by another 
caller, the data would be unavailable to SMF. 


SMF issues REQPGDAT during step termination. The 
REQPGDAT sysevent must be issued prior to the JOBTERM 
sysevent (code 9) because the address space data is reset 
upon receipt of JOBTERM. 


Reg O, bytes 0-1: ASID or zero. 

Reg O, byte 3: Sysevent code. 

Reg 1, bytes 0-3: Contains the address of a 14-word area where 
the paging data is to be stored. 


Paging data supplied by SRM: 


Word 1 -Count of non-VIO page-ins. 
Word 2- Count of non-VIO Page-outs. 
Word 3- Count of non-VIO reclaims. 
Word 4- Count of VIO page-ins. 

Word 5- Count of VIO page-outs. 

Word 6 - Count of VIO reclaims. 

Word 7 - Count of pages swapped in. 
Word 8 - Count of pages swapped out. 
Word 9 - Count of swapouts. 

Word 10 - Count of common area page-ins. 
Word 11 - Count of common area reclaims. 
Word 12 - Count of pages stolen. 

Word 13, 14 - Count of CPU page-seconds. 


Reg 15, byte 3: Indicates whether data was successfully 
returned (00), or not (04). 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 
Mnemonic: 

Meaning of Mnemonic: 
Purpose: 


Circumstances: 


Inputs: 


Outputs: 


28 (hex) 

COPY DMDT 

Copy domain table information. 

Obtain a copy of the SRM’s domain table. 


The operator has issued the DISPLAY command with the 
DMN parameter. 


Reg 0, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Contains the address of a 2584-byte 
fixed data area. 


Reg 1 contains the same address as input. 


The fixed data area On output contains: 
Bytes 0-1: Number of valid domains. 
Bytes 2-3: Reserved. 
Bytes 4-2584: Copy of SRM’s domain table. 
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Sysevent Code: 29 (hex) 

Mnemonic DONTSWAP 

Meaning of Mnemonic: Address Space is now not swappable. 

Purpose: Indicates to the SRM that the issuing address space must not 


be swapped until further notice. 
Circumstances: Application dependent. 


Inputs: Reg O, bytes 0-1: ASID of issuing address space, or zero. 
Reg O, byte 3: Sysevent code. 


Outputs: Reg 1, byte 3: Contains X’04’ if request is not for the 
current address space; contains X’00’ if the request to mark 
the address space as non-swappable was honored; contains 
X’08’ if request was not authorized, or if the outstanding 
count of DONTSWAP requests (code 29) has reached its 
maximum value. 


Note: Nonswappable status is reset at the time of attach 
by initiator (code OA) and detach by initiator (code OB). 
That is, nonswappable status it not carried across job 





steps. 
Sysevent Cade: 2A 
Mnemonic: OKSWAP 
Meaning of Mnemonic: Memory now swappable. 
Purpose: Indicates to the SRM that the issuing address space may now 
be swapped. 
Circumstances: Application dependent. 
Inputs: Reg O, bytes 0-1: ASID of issuing address space, or zero. 


Reg O, byte 3: Sysevent code. 


Outputs: Reg 1, byte 3: Contains X‘04’ if request is not for the 
current address space; contains X‘0O0’ if the request to mark 
the address space as swappable was honored; contains 
X’08’ if request was not authorized. 
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The Use of GTF to Track Sysevents (continued) ) 


Sysevent Code: 2B 

Mnemonic: REQSWAP 

Meaning of Mnemonic: Request to swap out address space. 

Purpose: A particular address space is required to be swapped out. 
Circumstances: An address space is being requested to release the real storage 


frames it currently occupies. At the time of the subsequent 
swap-in, the Real Storage Manager re-allocates real storage 
frames to the swapped-in address space. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Address of ECB to be posted. 


Outputs: Reg 1, byte 3: Contains X‘00' if the swap-out request was 
honored; X‘04’ if the request was ignored because of the 
non-swappable status of the indicated address space; 
contains X‘08’ if address space is being swapped out. 





Sysevent Code: 2C 

Mnemonic: BRINGIN 

Meaning of Mnemonic: Request to swap in address space. 

Purpose: A particular address space is required to be swapped in. J 
Circumstances: The current job in this address space has been canceled. If 


BRINGIN were not issued, an address space that had been 
swapped out because of a shortage might be kept out until 
the shortage had been relieved. 


Inputs: Reg QO, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 

Outputs: Reg 1, byte 3: Contains X’00’ if the swap-in request was 
honored; X‘0O8’ if address space is currently in the process of 
being swapped. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 2D 

Mnemonic: WKLDINIT 

Meaning of Mnemonic: Workload activity measurement initialization. 

Purpose: Permits MF/1 and RMF to inform the SRM to start collecting 


workload activity data by Performance Group Period (PGP), 
and provides the buffer used for data collection. 


Circumstances: MF/1 or RMF workload activity measurements are being activated. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: The address of a global data collection 
buffer. 


Outputs: Reg 1, bytes 0-3: 0 if data collection is successfully 
initialized. 

Reg 15, byte 3: X’O0’ if the request was honored, and no 
exception conditions were found; X’08’ if a request to 
start workload activity data collection was rejected 
because of an incorrect buffer size; X‘20’ if data collection 
is already active. 





Sysevent Code: 2E 

Mnemonic: WKLDCOLL 

Meaning of Mnemonic: Workload activity measurement collection. 

Purpose: Permits MF/1 and RMF to retrieve a copy of the data collected 


since the previous WKLDCOLL or WKLDINIT sysevent (code 
2D). If, however, the IPS has changed, MF/1 or RMF will issue 
the WKLDTERM sysevent (code 2F), followed by WKLDINIT 
to provide a different data collection area. 


Circumstances: End of an MF/1 or RMF measurement interval. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg 0, byte 3: Sysevent code. 
Reg 1, bytes 0-3: The address of a fixed buffer into which 
the collected workload activity measurements are to be 
copied. 


Outputs: Reg 1, bytes 0-3: Unchanged 
Reg 15, byte 3: X‘QO’ if the request was honored, and no 
exception conditions were found; X‘04’ if previously 
started workload activity data collection has been stopped 
because of an IPS change; X’40’ if the data collection 
buffer has not been established. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 2F 
Mnemonic: WKLDTERM 
Meaning of Mnemonic: Workload activity measurement termination. 
| Purpose: Permits MF/1 and RMF to inform the SRM to stop collecting 


workload activity data, and retrieve the buffer used for data collection. 


| Circumstances: MF/1 or RMF workload activity measurements are being 
terminated, or an IPS change has occurred. 


Inputs: Reg O, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 0-3: Zero. 


Outputs: Reg 1, bytes 0-3: The address of the global, fixed, workload 
activity data collection buffer that is no longer being 
used by the SRM. 


Reg 15, byte 3: X‘O0’ if the request was honored, and no 
exception conditions were found; X‘40’ if the data 
collection buffer has not been established. 





Sysevent Code: 30 (hex) 
Mnemonic: None 
| Purpose: Issued by the SRM itself in order to invoke its control . 3 
routine immediately without waiting for a sysevent issued by 


another component. 


Inputs: Reg 0, bytes 0-1: ASID or zero. 
Reg O, byte 3: Sysevent code. 
Reg 1, bytes 1-3: Address of system resource block under 
which this sysevent is issued. 


Outputs: None. 
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The Use of GTF to Track Sysevents (continued) 





Sysevent Code: 31 (hex) 

Mnemonic: REQSVDAT 

Meaning of Mnemonic: Request Service Data. 

Purpose: Permits SMF to obtain service-related data for a given 


address space. 
Circumstances: SMF issues REQSVDAT during job or session termination. 


Inputs: Reg O, bytes 0-1: ASID or 0. 
Reg 0, byte 3: Sysevant code. 
Reg 1, bytes 0-3: The address of a 4-word fixed area where 
the service data is to be stored. 


Outputs: The 4-word area contains: 


Word 1 - Total service for the job or session. 
Word 2 - Total transaction active time. 
Word 3: 
Bytes 0-1: Performance group number last 
assigned to the address space. 
Bytes 2-3: For aTSO address space, the total 
number of transactions. For other 
address spaces, 0. 
Word 4 - Total job or session residence time. 


Reg 15, byte 3: 


00 — Normal completion. 
04 — Data was lost due to accumulation control 
block error. 
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c 


Figure 5-7 depicts a listing that shows real frame shortages, as indicated 
by occurrences of AVQLOW (code X‘17’) and AVQOK (code X°18’) records 
sorted by relative time of day. The coded numeral ‘!’ in the last column 
indicates an AVQLOW non-critical threshold, and the numeral ‘2’ indicates 
an AVQLOW critical threshold. Note that at relative TOD 0.0 a non-critical 
AVQLOW occurred, followed by five critical AVQLOWs. Finally at relative 
time 0.65 an AVQOK occurred, signifying a temporary end to the real frame 
shortage. 


LIST OF SYSTEM RECORDS 


SYSEVENT 
CODE CODE 


DELTA TOD RELATIVE R1,B3 


(HEX) 


17 
17 
17 
17 
17 
17 
18 
17 
17 
18 
17 
17 
18 
17 
18 


NAME 


AVQLOW 
AVQLOW 
AVQLOW 
AVQLOW 
AVQLOW 
AVQLOW 
AVQOK 

AVQLOW 
AVQLOW 
AVQOK 

AVQLOW 
AVQLOW 
AVQOK 

AVQLOW 
AVQOK 


. 000000 
- 139316 
-045019 
.041238 
.013628 
-402581 
.010584 
- 660104 
- 460672 
- 007536 
-513137 
- 262811 
-005968 
-275185 
-927716 


OAnNnNnNNRPrRrRPOoOoaoocoo°oo 


TOD 


-000000 
- 139316 
- 184335 
- 225573 
- 239201 
-641782 
- 652366 
~ 312469 
~773141 
- 780677 
- 293814 
-556625 
- 562593 
-837777 
- 765494 


(indicator) 


Nr Ne NNN N NYOF 


— 








Figure 5-7. Instances of Real Frame Shortages, Distributed by Time of Day 


A reasonable question to be asked is: How long did the real frame shortage 
last? This question can be answered by means of pencil, paper, and the report 
in Figure 5-7, or by use of the reduction program to produce the report shown 
in Figure 5-8. In Figure 5-8 four non-critical AVQLOWs were issued and seven 
critical AVQLOWSs were issued. The average amount of time spent at AVQLOW 
was approximately 0.58 seconds, with all durations being less than 1 second. 
During this analysis period the total time spent at AVQLOW was 2.3 seconds. 


DISTRIBUTION OF AVQLOW TIMES 


COUNT COUNT COUNT M(C17-C18) PERCENTS AVQTIME(C17-C18) MAX 
C17 C17c C18 AVQTIME <= <= 


T(C17-C18) 
> RELATIVE AVQTIME 


(AVERAGE) : : 0.5 0.7 300 TOD (TOTAL) 


: .0 25.0 25.0 ; : 0.0 8.765494 


Figure 5-8. Distribution of Real Frame Shortages 
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TCAM Tuning Considerations ) 
This section describes special considerations for page fixing TCAM in areas 
containing TCAM CSECTs, modules, and control blocks. 


It covers three topics related to page fixing and page faults: 
e Packaging the MCP to Minimize Page Fixes and Page Faults 
e Coding INTRO Operands to Minimize Fixed Pages 
e@ Ordering of OPENs to Minimize Fixed Pages for LCBs and SCBs. 


For additional performance guidelines on TCAM, refer to the OS/VS2 TCAM 
Programmer’s Guide and the OS/VS TCAM User’s Guide (GC30-2025) which give 
guidelines on efficient section ordering of the Message Control Program (MCP) and 
explanations of space utilization caused by selecting certain TCAM options. These 
guidelines and explanations should help minimize the number of fixed pages 
required in the TCAM system, and also minimize the number of page faults. 


Packaging the MCP to Minimize Page Fixes and Page Faults 


The parmlib member, IEAPAKOO, can be used to group TCAM modules in the 
pageable link pack area (PLPA). The user can reduce page faults by grouping 
modules that refer to each other during execution. Suggested groupings are: 


e TCAM open modules 
e TCAM close modules 
e TCAM error recovery modules. 


In addition, TCAM operator control modules can be grouped in the PLPA according 
to those that are most often used. For further information on IEAPAKOQO, see 
“Part 2: System Initialization - PARMLIB Members” in this manual. For 
information on the PLPA, see the performance topic, “The Pageable Link Pack 
Area: Its Advantages and Uses” in Part 5. The following control blocks and 
modules will be fixed by TCAM and should be grouped by the linkage editor 
ORDER control statement as described below: 


e Control blocks: 


Assembled in the MCP — CSECT 
Address Vector Table (AVT) | MCP 





Data Control Blocks (DCBs) MCP 

Device Characteristics Table IEDQSTCS 

Invitation Lists MCP 

Option Tables IEDQOPC, IEDQOPT 

Queue Control Blocks (QCBs) IEDQQCBC 

Station Control Blocks (SCBs) IEDQSCBC 

Terminal Entries IEDQTRMC 

Terminal Name Table (TNT) IEDQTNT J 
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Packaging the MCP to Minimize Page Fixes and Page Faults (continued) 


Dynamically Acquired (via GETMAIN): 
Buffer Units 
Channel Program Blocks (CPBs) 
Dial SCBs 
Line Control Blocks (LCBs) 


e Loaded modules: 


Attention Handler Routine 
Channel End Appendage 
I/O Trace Table 

PCI Appendage 

Special Characters Table 
Start I/O Appendage 


The module names for the TCAM routines listed above can be found in 
OS/VS2 TCAM Logic, SY30-2040). 


The linkage editor ORDER control statement can be used to cause the TCAM MCP 
to be loaded on a page boundary and to group CSECTs of the MCP that are fixed. 
The ORDER statement can also be used to group modules in the MCP according to 
their use. Section 4 of OS/VS2 TCAM Logic correlates TCAM modules 

to TCAM function in the MCP. The user can determine the order in which his MCP 
calls on TCAM modules and then use the ORDER statements to cause TCAM to 
order the MCP accordingly, thus reducing the number of page faults between 
execution of different modules. The following example shows how the ORDER 
statement can be used to group CSECTs and modules so that the number of page 
fixes is minimized: 


ORDER MCP (P) ee page boundary alignment by the linkage 


ORDER IEDQQCBC 

ORDER IEDQTNT 

ORDER IEDQTRMC 

ORDER IEDQOPT IEDQOPT and IEDQOPC are in the MCP only if the 
ORDER IEDQOPC OPTION facility is used. 

ORDER IEDQSTCS 

ORDER IEDQSCBC 


ORDER IEDAYZ ! IEDAYZ and IEDQKAO?2 are page fixed only if TSO 


is included in a TCAM system running with an IBM 


ORDER IEDQKA02 2701, 2702, or 2703 control unit. 


ENTRY MCP 
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Coding INTRO Operands to Minimize Fixed Pages ) 


By carefully selecting operands of the INTRO macro instruction, the user can 
minimize the number of fixed pages required for the following if real storage size is 
critical: 


e Station Control Blocks (SCBs). 
e I/O Trace Table. 

e Buffer Units. 

e Channel Program Blocks (CPBs). 


The pages for these control blocks are obtained and fixed during TCAM 
initialization. 


The following operands of the INTRO macro instruction determine the number of 
pages that are fixed: 


USEREG= 

UNITSZ=, KEYLEN= ___ (See note below) 
LNUNITS= 

MSUNITS= 

TRACE= 

CPB= 


Station Control Blocks Jd 


The USEREG= operand of INTRO specifies the number of registers that can be 
saved in a station control block (SCB). SCBs that are assembled in the MCP are 
fixed in the IEDQSCBC CSECT. The size of an SCB is eighty-four bytes plus four 
bytes for each register saved. The size of IEDQSCBC can thus be unnecessarily 
increased if the user creates register save areas in each SCB when he does not need 
them. 


Note: KEYLEN= and UNITSZ= are mutually exclusive. UNITSZ= is the more J 
preferred term and will be used for the remainder of this topic. 
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I/O Trace Table, Buffer Units, and Channel Program Blocks 


Space is allocated for the I/O trace table, the buffer units, and the CPBs by one 
GETMAIN macro. The GETMAIN is for the number of pages (4096 bytes per 
page) needed to contain all of the control blocks. The user can determine the 
number of pages required as follows: 


1. Determine the number of pages needed to contain the I/O trace table. 
Specify this storage by the TRACE= operand. Each trace entry is sixteen 
bytes long. In addition, thirty-two bytes of control information are required 
for the entire table. Therefore: 


Trace table size = 16 (number of trace entries) +32 


2. If any space remains in the last page of the I/O trace table, use it for buffer 
units as long as each unit fits completely within the page. When the space in 
the page is insufficient, specify additional pages as described below. In each 
additional page, the last buffer unit must fit completely within the page; 
that is, it must not cross a page boundary. 


The amount of storage for the buffer units is specified by the UNITSZ=, 
LNUNITS=, and MSUNITS= operands. The total number of units is equal 
to the sum of LNUNITS and MSUNITS. The size of each unit is found by 
adding twelve (or twenty if TCAM is in a VT AM system) to the 
UNITSZ=value. The extra bytes are used by TCAM for internal control 
information. If the buffer unit size is not a multiple of a double word, 

the value will be rounded up to the next double word. 


3. If any space remains in the last page needed by the buffer units, use it for the 
CPBs. Additional pages may be needed to contain all the CPBs. As with 
buffer units, CPBs cannot cross a page boundary. 


The amount of storage required for CPBs is determined by the CPB= and 
UNITSZ= operands. The CPB= operand gives the number of CPBs. The size 
of each CPB is found by adding seventy-two (72) to the buffer unit size. 


When the number of pages required has been determined, then the GETMAIN for 
the storage is issued. The space within the pages is allocated to the control blocks 
and initialized. Any space within a page that is not used because a buffer unit or 
CPB would not fit completely is freed. The address of the storage and its length is 
saved for the page fix which will be issued during the TCAM OPEN macro execution. 


The following example shows how the proper choice of INTRO operand values can 


help minimize the number of pages that are fixed by TCAM. This example 
is for TCAM in a non-VTAM environment. 
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LNUNITS= 50 MSUNITS= 21 LNUNITS= 50 MSUNITS= 21 
TRACE= 200 UNITSZ= 116 TRACE= 198 UNITSZ= 116 
CPB= 20 CPB= 20 


Page Allocation Page Allocation 


198 trace entries 
7 buffer uriits 
32 buffer units 
32 buffer units 
20 CPBs 
unused 


200 trace entries 
6 buffer units 
unused 
32 buffer units 
32 buffer units 
1 buffer unit 
19 CPBs 
unused 
1 CPB 
unused 


Total Pages Fixed: 4 


Total Pages Fixed: 
Total Unused Bytes: 96 


Total Unused Bytes: 


LNUNITS= 49 MSUNITS= 21 LNUNITS= MSUNITS= 21 
TRACE= ste UNITSZ= 116 TRACE= 200 UNITSZ= 116 
CPB= CPB= 


200 trace entries 200 trace entries 

6 buffer units 6 buffer units 
unused unused 

32 buffer units 32 buffer units 

32 buffer units 32 buffer units 

20 CPBs 1 buffer units 

unused 19 CPBs 

unused 


Total Pages Fixed: Total Pages Fixed: 
Total Unused Bytes: Total Unused Bytes: 





In the initial case, five pages are needed to contain the control blocks. However, 
3896 bytes of the last page are not used even though the entire page is fixed. 
Changes 1, 2, and 3 show that by altering the INTRO operands TRACE=, 
LNUNITS=, and CPB= respectively, the fifth page is not needed. 


Figure 5-9 shows the number and size of both the buffer units and CPBs available 
per page in relation to the UNITSZ=operand for a non-VTAM environment. It also 
shows the number of units CPBs that can be fixed on a page, along with the remain- 
ing unused portion, depending on the various values of UNITSZ. For further 
information on the SCB I/O trace table, buffer units, and channel program blocks, 
see OS/VS2 TCAM Logic, SY30-2059. 
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Figure 5-9. Available Buffer Units and CPBs According to UNITSZ Operand (for a non-VTAM 
environment) 


Ordering OPEN Macros to Minimize Fixed Pages 
for LCBs and SCBs 


The user can significantly reduce the number of fixed pages required for Line 
Control Blocks (LCBs) and Station Control Blocks (SCBs) through efficient 
ordering of the TCAM OPEN macro instructions. These control blocks are 
obtained by TCAM during OPEN execution of line group DCBs. 

@ One LCB is obtained for each line in a line group. 


e@ One SCB is obtained for each line in a dial line group. 


The table in Figure 5-10 indicates the size of an LCB for each terminal type and 
the maximum number of lines in a group that will fit into two pages of storage. 
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Maximum Number of 
Terminal Type LCB Size LCBs in 2 Pages 
200 39 


2260 Local 

3270 Local 

7770 

1050 

1030 

115A 

2740 

2741 

115A-WTTA 

5041 

TWX 

WTT 

2740 Dial 

1050 Dial 

2740 Contention 
Autopoll: start/stop 
BSC 





200 
216 






























Note: The LCBs for a line group are allocated contigquously in storage. Contiguous to 
the allocated storage for LCBs are eight bytes of storage for each of the LCBs in the line 
group. This storage is used to contain the threshold values for each line. (See the 
THRESH= operand of the INTRO macro.) 


Figure 5-10. LCB Sizes By Terminal Type 


The following restrictions and techniques will affect the allocation of LCBs and 
SCBs. 


Restrictions 


The Channel Program Area (CPA) of the LCB must be in fixed storage and cannot 
cross a page boundary. The CPA begins at offset 144 (X‘90’) in the LCB and 
extends to the end of the LCB. For all LCB sizes, this restriction is not a problem 
when the LCBs for a group can fit into one or two pages. (The LCBs for a line 
group must be contiguous in storage.) If more than two pages are needed, TCAM 
imposes the following restrictions (except for 2260L and 3270L line groups): 


@ The LCB size is changed to 248. 
@ Only 132 lines are allowed in the line group. 
e@ The first LCB for the group is allocated at an offset of 24 in the first page. 


This offset value, called the alignment, ensures that up to 132 LCBs can be 
allocated without a CPA crossing a page boundary. 
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Techniques 


TCAM issues GETMAIN macros in page increments for LCBs and SCBs. 

The storage in a page that is not allocated for control blocks is referred to as 
“available storage’. It is chained with other blocks of available storage. The first 
word of each available storage block points to the next available storage block, or 
to zero if it is the last block in the chain. The second word contains the length of 
the available storage block. The pointer to the first available storage block is kept 
in the TCAM CVT extension control block (TCX). If the LCBs for a line group will 
fit into an available storage block, then the block is used. What is not used remains 
in the chain of available storage. If all of the available storage in the page is used, 
then that page is removed from the chain. If no available storage block is large 
enough to contain the requested space, then a GETMAIN for the number of pages 
needed is issued. If after allocating space in the acquired page or pages there is 
storage left over, it is added to the “available storage” chain. 


Dial line groups require additional processing. Preceding the space for the line group 
are eight bytes of control information. If the line group requires more than two 
pages for LCBs, an alignment value of 16 will be issued. The 16 byte alignment, 
plus the eight bytes of control information, will assure that the CPAs do not cross 
page boundaries for up to 132 lines. Also, an SCB will be obtained for each line in 
the group. The length of an SCB, in bytes, is: 


length of SCB= 84+ 4(USEREG), where USEREG is the value of the USEREG= 
operand of the INTRO macro. 


The SCBs for a line group are obtained as a contiguous block of storage and will be 
allocated in the LCB available storage, if possible. To ensure that a minimal number 
of pages are fixed for LCBs and SCBs, open the largest line groups first (that is, the 
ones with the most lines). 
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Miscellaneous Performance Guidelines 


The following tuning guidelines are reprinted from an Installation Newsletter. 


e Data Set Placement: Locate the VTOC near the center of the pack, and place 


heavily used data sets close to the VTOC. Note that the relative importance 


(frequency of use) of system data sets has changed from that in OS/MVT. For 
example, SYS1.SVCLIB and SYS1.LINKLIB had high frequency usage in 
OS/MVT. In MVS, the modules previously located on these data sets now 
reside in SYS1.LPALIB. The SYSRES data set placement used for benchmark 


measurement runs was: 


Contents 


SYS1.LPALIB 
SYS1.PARMLIB 
SYS1.DUMP00 
SYS1.DUMP01 
SYS1.DSSVM 
SYS1.NUCLEUS 
SYS1.DCMLIB 
SYS1.LOGON 
SYS1.SVCLIB 
SYS1.CMDLIB 
SYS1.MACLIB 
SYS1.PROCLIB 
SYS1.UADS 
SYS1.BRODCAST 
VTOC 
CATALOG 
SYS1.STGINDEX 
SYS1.LINKLIB 
SYS1.MANX 
SYS1.MANY 
SYS1.HELP 
SYS1.TELCMLIB 
SYS1.IMAGELIB 
SYS1.LOGREC 


Cylinder 


(1-36) 
(37-46) 
(47-52) 
(53-56) 
(57-59) 
(66-80) 
(81-82) 
(136-137) 
(138-142) 
(143-152) 
(153-188) 
(189-194) 
(195-198) 
(199-199) 
(200-200) 
(201-225) 
(226-231) 
(232-271) 
(272-281) 
(282-291) 
(388-388) 
(391-398) 
(399-399) 
(400-401) 


e Program Product Region Sizes: Specify a region size in the JCL for all Program 
Products which use GETMAIN to obtain all available storage. This will prevent 
the program from getting eight megabytes of virtual storage. 


@ Use of Initiators: Do not run in a highly overinitiated environment. Start at a 
conservative initiator level for example, and work up to the number of 
initiators that gives the balance of throughput and distribution of service that is 


desired. 
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Miscellaneous Performance Guidelines (continued) j 
e Journaling: Measurements have shown up to 34% (a significant) increase in 


overhead because of journaling when running VIO and a workload containing 
many job steps. 
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multiple performance periods 186 (VS2.03.807) 

performance objectives 178-181 (VS2.03.807) 

performance objectives and ISVs 181-183 (VS2.03.807) 
concatenating libraries to LINKLIB 139 
concurrent paging 158.10 (VS2.03.807) 
CONFIGCH sysevent 278 
configuration, system, determining changes to 262 
contention 

channel and device 158.2 (VS2.03.807) 

for paging devices 158.8 (VS2.03.807) 
contention factors, system 166 (VS2.03.807) 
contention for storage, excessive 165 (VS2.03.807) 
contention index 

definition 172 (VS2.03.807) 

how to calculate 201 (VS2.03.807) 

selecting domain weights 201 (VS2.03.807) 

use of bySRM_ 172, 173 (VS2.03.807) 
contention, SRM throughput control 162 (VS2.03.807) 
CPU activity report 

description of 210 

how to use it 224 
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CPU load adjusting 
discussion 165 (VS2.03.807) 
factor in swap decisions 183 (VS2.03.807) 
CPU 
monitoring of usage 166 (VS2.03.807) 
overutilized 166 (VS2.03.807) 
task execution time 198 (VS2.03.807) 
underutilized 166 (VS2.03.807) 
CPU parameter 
resource factor coefficient 202.22 (VS2.03.807) 
service definition coefficient 202.19 (VS2.03.807) 
CPU service, selecting coefficient value 198 (VS2.03.807) 
CPU service units 174 (VS2.03.807) 
crash, system, how to warm-start after 22 
critical storage shortages 168 (VS2.03.807) 
CSA 
excluded from common areas 90, 158.1 (VS2.03.807) 
paging data set size estimation 158.10 (VS2.03.807) 
CSA parameter in IEASYSxx 98 
CTRLPROG macro instruction 119 (VS2.03.807) 
current MPL 200 (VS2.03.807) 
cut-off workload level 
definition 177 (VS2.03.807) 
effect of 182 (VS2.03.807) 
limit on load adjusting values 187 (VS2.03.807) 
use of 202.1, 202.13 (VS2.03.807) 
CVIO 
parameter 22 (VS2.03.807) 
specification 158.9 (VS2.03.807) 
CVIO parameter in IEASYSxx 99 
CVOL usage (see Using OS Catalog Management with the 
Master Catalog: CVOL Processor and VSAM Programmer's 
Guide) 


DATASET macro instruction 
DUPLEX parameter specification 102.2 (VS2.03.807) 
for primary PLPA copy 158.8 (VS2.03.807) 
PAGE parameter specification 115-116 (VS2.03.807) 
SWAP parameter specification 125.1 (VS2.03.807) 
DATASET sysgen macro 
rules and syntax example for specifying EXCP 
appendages 53 
DEFINE PAGESPACE command 40 (VS2.03.807) 
DEFINE PAGESPACE processor 
general use 116 (VS2.03.807) 
page space shortage 118 (VS2.03.807) 
defining page data sets 40 (VS2.03.807) 
detected wait swap count 202.12 (VS2.03.807) 
detection of wait states 164 (VS2.03.807) 
DEVALLOC sysevent 278 
device activity report (MF/1) 
description of 215 
how to use it 226 
device allocation performance 252 
guidelines for improving allocation response 253 
order in which requests are serviced 252 
questions and answers 256 
device allocation, SRM 167 (VS2.03.807) 
device class selection 208 


device contention 
ASM _ 158.8 (VS2.03.807) 
service bursting 158.2 (VS2.03.807) 
device preference table, use of 253 
device speed tradeoffs for paging 158.9 (VS2.03.807) 
device type parameter in VATLSTxx member 157 
device usage by ASM_ 158.9 (VS2.03.807) 
Direct Access Device Activity report 158.9 (VS2.03.807) 
dispatchable job mix 166 (VS2.03.807) 
dispatching priorities 
assigning of 202.16 (VS2.03.807) 
automatic priority group (APG) 164, 165 (VS2.03.807) 
evaluation and adjustment 202.8, 202.10 (VS2.03.807) 
guidelines for selecting 202 (VS2.03.807) 
performance characteristics 183 (VS2.03.807) 
queue, useof 164 (VS2.03.807) 
SRM control via 162, 164 (VS2.03.807) 
DMN parameter 202.19 (VS2.03.807) 
domain 
constraints (see domain constraints) (VS2.03.807) 
definition 170 (VS2.03.807) 
delay 202.9 (VS2.03.807) 
examples 171 (VS2.03.807) 
guidelines for defining 200 (VS2.03.807) 
MPL control over 170 (¥VS2.03.807) 
purpose of 160, 161 (VS2.03.807) 
special purpose 202 (VS2.03.807) 
specification 202.18 (VS2.03.807) 
SRM control via 161 (VS2.03.807) 
switching of 186 (VS2.03.807) 
weight (see domain weight) (VS2.03.807) 
domain constraints 
definition 170 (VS2.03.807) 
evaluation and adjustment 202.10, 202.14, 
202.15 (VS2.03.807) 
guidelines for selecting 200 (VS2.03.807) 
multiprogramming level 170 (VS2.03.807) 
specification 202.19 (VS2.03.807) 
weight 172 (VS2.03.807) 
domain weight 
definition 172 (VS2.03.807) 
evaluation and adjustment 202.10 (VS2.03.807) 
guidelines for selecting 200 (VS2.03.807) 
specification 202.19 (VS2.03.807) 
use of 201,202 (VS2.03.807) 
DONTSWAP sysevent 285 
DPRTY parameter 202.16 (VS2.03.807) 
DSV parameter in SMFPRMxx 149 
dump 
ABEND dump parameter 
IEAABD00 48 
IEADMP00 58 
SVC dump 100-102 
DUMP parameter in IEASYSxx 100 
duplex page data set specification 102.1 (VS2.03.807) 
DUPLEX parameter 
description 102.1 (VS2.03.807) 
overview 87 (VS2.03.807) 
sysgen macro — initialization parameter 
equivalence 85 (VS2.03.807) 
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DUPLEXDS, NAME 

keyword combination 22 (VS2.03.807) 

parameter 85 (VS2.03.807) 
duplexing, CLPAIPL 158.2 (VS2.03.807) 
DUR, performance period duration 202.20 (VS2.03.807) 
duration of performance periods 

classes and subclasses 202.1 (VS2.03.807) 

in real time units 202.9 (VS2.03.807) 

selecting values 202.1 (VS2.03.807) 

(see also performance period) (VS2.03.807) 
dynamic allocation, invoking from abatchjob 254 
dynamic allocation of paging space 158.12 (VS2.03.807) 


elapsed time of a transaction 174,175 (VS2.03.807) 
ENQ exchange swap count 202.14 (VS2.03.807) 
ENQHOLD sysevent 274 
ENQRLSE sysevent 274 
enqueue bottleneck 167 (VS2.03.807) 
enqueue contention 202.14 (VS2.03.807) 
enqueue delay minimization 166 (VS2.03.807) 
enqueue processing, SRM 162 (VS2.03.807) 
enqueue residence value (ERV) 
definition 166 (VS2.03.807) 
ENQ swap out count 202.14 (VS2.03.807) 
specification 202.22 (VS2.03.807) 
ERV (see enqueue residence value) (VS2.03.807) 
example 
AMASPZAP service aid 158.4 (VS2.03.807) 
calculating reserve address space 158.4 (VS2.03.807) 
common page data set sizing 158.6 (VS2.03.807) 
duplex page data set sizing 158.7 (VS2.03.807) 
HMASMP service aid 158.5 (VS2.03.807) 
local page data set sizing 158.7 (VS2.03.807) 
PAGE parameter syntax 117 (VS2.03.807) 
PLPA page data set sizing 158.6 (VS2.03.807) 
sizing swap datasets 158.8 (VS2.03.807) 
space calculation 158.5 (VS2.03.807) 
syntax of PAGNUM parameter 119 (VS2.03.807) 
exchange on recommendation value swap 
count 202.12 (VS2.03.807) 
exchange swap 
definition 163 (VS2.03.807) 
factors contributing to decision 183 (VS2.03.807) 
workload level recommendation 177 (VS2.03.807) 
exhaustion of paging space 158.11 (VS2.03.807) 
EXCP appendage, how to specify 53 
EXCP count maintained by SRM 198 (VS2.03.807) 
EXCP relationship to I/O service unit 198 (VS2.03.807) 
execution characteristics 
discussion 161 (VS2.03.807) 
batch vs. TSO 200 (VS2.03.807) 
EXT parameter in SMFPRMxx 150 


FIX parameter in IEASYSxx 103 
fixed-head devices 158.1, 158.9 (VS2.03.807) 
fixed impact of allocations 167 (VS2.03.807) 
fixed link pack area list 61 
fixed priorities 165 (VS2.03.807) 
fixed requirements 

discussion 190 (VS2.03.807) 

not being met 202.8 (VS2.03.807) 


formatting a data set for VSAM 102.2 (VS2.03.807) 
formula for estimating paging data set sizes 158.10 (VS2.03.807) 
FREE=CLOSE, use of 254 


GMT (Greenwich mean time) 144 
GTF 
member of parmlib 43 
parameters 45 
starting GTF (general) 39 
starting via the IBM-supplied procedure 43,45 
used to trace sysevents 263 
GTFPARM 
detailed description 43 
synopsis 27 
guaranteed access to real storage 201 (VS2.03.807) 


JARDCPY parameter in IEASYSxx 104 
relationship with HARDCOPY parameter of SCHEDULR 
macro at sysgen (see “Default Value” 105) 
IMASMP service aid 158.5 (VS2.03.807) 
10W page data sets are specified 116 (VS2.03.807) 


IEAABD00 (see also IEADMP00) 
detailed description 47 
synopsis 27 
IEAAPFxx 
detailed description 52 
synopsis 28 
IEAAPPOO 
detailed description 53 
synopsis 28 
IEABLDxx 
default member, IBM-supplied 57 
detailed description 56 
synopsis 28 
IEADMP00 (see also IEAABDO0) 
detailed description 58 
synopsis 29 
IEAFIXxx 
detailed description 61 
synopsis 29 
IEAIPSxx (see IPS) (VS2.03.807) 
IEALIMIT value 158.7 (VS2.03.807) 
IEALOD00 (see also pageable link pack area) 
detailed description 72 
synopsis 30 
TEALPAxx (see also MLPA and link pack area, pageable) 
detailed description 73 
synopsis 30 
IEAOPTxx 
evaluation and adjustment 202.8 (VS2.03.807) 
guidelines for preparing 202.3 (VS2.03.807) 
parameter concepts 187 (VS2.03.807) 
parameter Specifications 202.22 (VS2.03.807) 
relation toSRM 160 (VS2.03.807) 
{[EAPAKBA (batch default pack list), description of 81 
IEAPAK00 (see also link pack area, pageable) 
default lists, IBM-supplied 79 
detailed description 78 
ISAM pack list, suggested 241 
synopsis 31 
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IEAPAKTS (TSO and batch default pack list), description of 80 
[EAS YSxx 
containing primary PLPA copy 158.8 (VS2.03.807) 
source for PAGE parameter 116 (VS2.03.807) 
source for PAGNUM parameter 119 (VS2.03.807) 
SWAP parameter source 125.1 (VS2.30.807) 
IEAS YSxx (see also individual parameters) 
default contents 91 
detailed description 85 
incompatibilities with MVT and VS2 Release 1 
parameters 88 
MVT parameters, unsupported 88 
overview of parameters 86 
related sysgen macros 81 
synopsis 32 
syntax rules 91 
VS2 Release 1 praameters, unsupported 90-91 
IEASYS00 
containing primary PLPA copy 
default contents 91 
how overridden by IEASYSxx and operator 85 
source of PAGE parameter 116 (VS2.03.807) 
source of PAGNUM parameter 119 (VS2.03.807) 
source of SWAP parameter 125.1 (VS2.03.807) 
sysgen parameters copied to IEASYS00O 85 
IEA890I error message 158.4 (VS2.03.807) 
IEBUPDTE, example of statements 35 


158.8 (VS2.03.807) 


IKJPRMOO 
detailed description 131 
synopsis 32 
ILRSLOTC 
constant 158.11 (VS2.03.807) 
value 
changing 158.4 (VS2.03.807) 
description 158.3-158.4 (VS2.03.807) 
example 158.4-158.5 (VS2.03.807) 
ILRSLOTV 
constant 158.11 (VS2.03.807) 
value 
changing 158.4 (VS2.03.807) 
description 158.4 (VS2.03.807) 
example 158.4-158.5 (VS2.03.807) 
ILROO9I message 125.2 (VS2.03.807) 
importance 
ofadomain 172 (VS2.03.807) 


176,177 (VS2.03.807) 
161 (VS2.03.807) 
202 (VS2.03.807) 


of an address space 
of types of work 
IMS dispatching priorities 
INITATT sysevent 270 
INITDET sysevent 270 
initial IPS and OPT, preparation of 191 (VS2.03.807) 
initialization, ASM  158.1-158.12 (VS2.03.807) 
initialization, system overview 20 
initialization, use of parmlib 24 
initiator classes and period durations 202.1 (VS2.03.807) 
initiator dispatching priority 202 (VS2.03.807) 
initiators, use of 303 
INLOCKHI (TSO parameter) 133 
INLOCKLO (TSO parameter) 133 
input terminal wait swap count 202.12 (VS2.03.807) 


installation performance specification (IPS) 
(see also IPS) (VS2.03.807) 
default 202.4 (VS2.03.807) 
evaluation and adjustment 202.8 (VS2.03.807) 
examples 202.6 (VS2.03.807) 
guidelines for preparing 191 (VS2.03.807) 
parameter concepts 169-186 (VS2.03.807) 
parameter specifications 202.17-202.21 (VS2.03.807) 
relation toSRM 160 (VS2.03.807) 
installation requirements, guidelines 189 (VS2.03.807) 
interval service value (ISV) 
definition 181 (VS2.03.807) 
competition for resources controlled by 181-183 (VS2.03.807) 
evaluation and adjustment 202.13 (VS2.03.807) 
guidelines for selecting 202.1 (VS2.03.807) 
preemption during ISV 182, 186, 202.13 (VS2.03.807) 
specification 202.20 (VS2.03.807) 
I/O activity, comparison between problem program and 
the system 262 
I/O device activity report (MF/1) 
description of 215 
how to use it 226 
1/O errors 
paging 158.11 (VS2.03.807) 
permanent 158.7 (VS2.03.807) 
I/O load adjusting 
device allocation 167 (VS2.03.807) 
factor in swap decisions 183 (VS2.03.807) 
I/O load balancing, by ASM_ 158.11 (VS2.03.807) 
1/O service, selecting coefficient value 198 (VS2.03.807) 
I/O service units 174 (VS2.03.807) 
I/O supervisor queues, ASM 158.10 (VS2.03.807) 
IOC parameter 
resource factor coefficient 
service definition coefficient 
IPL 
adding page space during life 
CLPA 102.1 (VS2.03.807) 
non-CLPA 102.1-102.2 (VS2.03.807) 
page data set number requirement 115 (VS2.03.807) 
SWAP parameter specification 125.1 (VS2.03.807) 
termination 117 (VS2.03.807) 
IPL, typesof 22 
IPS 
(see also installation performance specification) (VS2.03.807) 
changing the IPS between IPLs via SETIPS 38 
member description 63 
parameter in IEASYSxx 106 
parameter on SET command 202.16 (VS2.03.807) 
ISV parameter 202.20 (VS2.03.807) 
(see also interval service value) (VS2.03.807) 


202.22 (VS2.03.807) 
202.20 (VS2.03.807) 


118 (VS2.03.807) 


job classing, adjustment of 202.11 (VS2.03.807) 
JOBCAT DD statement, use of to speed catalog search 258 
JOBSELECT sysevent 269 

JOBTERM sysevent 269 

job wait limit (JWL parameter in SMFPRMxx) 147 

JWT (parameter in SMFPRMxx) 147 


L keyword 115 (VS2.03.807) 
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libraries that require authorization, how to specify 52 
LINKLIB 
concatenating libraries with 139 
link pack area 
default pack lists 79 
extension list (IEALPAxx) 73 
fixed, use of 242 
loading of 243-245 
pack list IEAPAKO0) 78 
pageable: advantages, uses, recommendations 240 
list capability for IPL and parmlib parameters 
description of operator responses needed to list IPL 
parameters (see Operator’s Library: OS/VS2 Reference 
(JES2) ) 
which parmlib members and IEASYSxx parameters can be 
listed 27 
LNK (parameter in IEASYSxx) 107 
LNKLSTxx 
detailed description 139 
synopsis 33 
load adjusting swap recommendations, 
use of 202.15 (VS2.03.807) 
load adjusting values 
cut-off workload level 187 (VS2.03.807) 
effect on swap analysis 187,188 (VS2.03.807) 
load list (member IEALODOO) 
detailed description 72 
synopsis 30 
log (see LOGCLS and LOGLMT) 
LOGCLS (parameter in IEASYSxx) 108 
logical channel utilization 166,167 (VS2.03.807) 
logical groups handled by Auxiilary Storage Manager, limit on 
the number of 110 
LOGLMT parameter in IEASYSxx) 109 
LOGONs 118 (VS2.03.807) 
long wait swap count 202.12 (VS2.03.807) 
LPA pages 115 (VS2.03.807) 
LSQA 
for swap sets 158.5 (VS2.03.807) 
pages for swap dataset 125.2 (VS2.03.807) 
space for swap data sets 125.1 (VS2.03.807) 


main storage service, selecting coefficient 
value 198 (VS2.03.807) 
MAN (parameter in SMFPRMxx) 147 
Mass Storage System 
MVIKEY00 (in SYS1.PARMLIB) 141-143 
PURGE parameter 120 
master catalog 116 (VS2.03.807) 
MAXUSER (parameter in IEASYSxx) 110 
mean-time-to-wait priority 165,202 (VS2.03.807) 
measurement facility (see MF/1) 
measurement facilities 158.10 (VS2.03.807) 
measurement tools 
MF/1 203 
SMF used to supplement MF/1 261 
sysevent trace (GTF function) 263 
MEMCREAT sysevent 268 
MEMDEL sysevent 268 


MF/1 
how to use it (introduction) 203 
messages 135-136 
operator start command, example of 205 
parameters 
conflicts between 207 
multiple sources of 205 
procedure, IBM-supplied 204 
reports and SMF records 
channel activity 212,225 
CPU activity 210,224 
device activity 215, 226 
how to use the reports 224 
paging activity 216, 227 
types of reports and SMF records 209 
workload activity 220-228 
used to determine ASM initialization 
requirements 158.7-158.8, 158.10 (VS2.03.807) 
minimum paging space 117 (VS2.03.807) 
MLPA 
duplexed for recoverability 98 (VS2.03.807) 
exclusion from common areas 90, 158.1 (VS2.03.807) 
paging data set size estimation 158.10 (VS2.03.807) 
parameter in IEASYSxx 111 
modified link pack area list (IEALPAxx) 73 
mount attribute (in VATLSTxx member) 
definition 158 
parameter position, meaning, and value range 157 
MOUNT commands 118 (VS2.03.807) 
mount message suppression (parameter in VATLSTxx 
member) 158 
movable-head devices 158.8-158.9 (VS2.03.807) 
MPL (see multiprogramming level) (VS2.03.807) 
MSO, service definition coefficient 202.20 (VS2.03.807) 
MSS (see Mass Storage System) 
multiprogramming level (MPL) 
adjusting function 165 (VS2.03.807) 
definition 170 (VS2.03.807) 
evaluation and adjustment 202.10, 202.11 (VS2.03.807) 
guidelines for selecting 200 (VS2.03.807) 
target MPL 170 (VS2.03.807) 
use of 170-172 (VS2.03.807) 
MVIKEYOO 
detailed description 141-143 
synopsis 33 


NEWIPS sysevent 280 

NIOWAIT sysevent 267 

NIP, writing PLPA to PLPA page dataset 116 (VS2.03.807) 
nucleus, map of (see NUCMAP) 

NUCMAP (parameter in IEASYSxx) 112 


OBJ, performance objective specification 202.20 (VS2.03.807) 
OLTEP, real region size needed 121 

operations, page/swap 158.1 (VS2.03.807) 

operator commands related to the SRM 202.16 (VS2.03.807) 
operator commands (system) used to tailor the system 37 
operator entry of parameters 23 

operator intervention (see OPI, and operator entry of parameters) 
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operator responses to SPECIFY SYSTEM PARAMETERS 
message (see Operator's Library: OS/VS2 Reference (JES2)) 

OPI 

parameter in IEASYSxx 113 

parameter in SMFPRMxx 150 
OPT 

(see also IEAOPTxx) (VS2.03.807) 

parameter in IEASYSxx 114 

parameter in SMFPRMxx 146, 166 
optimizing use of control mechanisms 202.12 (VS2.03.807) 
order for specifying page data sets 115 (VS2.03.807) 
output terminal wait swap count 202.12 (VS2.03.807) 
overriding 

page datasets 116 (VS2.03.807) 

swap datasets 125.1 (VS2.03.807) 
overspecifying space 158.9 (VS2.03.807) 
OWAITHI (TSO parameter) 133 
OWAITLO (TSO parameter) 134 


pack list (IEAPAK00) 

default pack lists 79 

description and use 78 

ISAM pack list, suggested 241 
page data set values 158.5 (VS2.03.807) 

definition 40 (VS2.03.807) 

page-out selection 158.12 (VS2.03.807) 

performance aspects 158.3 (VS2.03.807) 

specification order 115 (VS2.03.807) 

specification sources 116 (VS2.03.807) 
PAGE parameter 

contrasted with SWAP parameter 

specification 125.1 (SV2.03.807) 

description 115-119 (VS2.03.807) 

for primary PLPA copy’ 158.8 (VS2.03.807) 

sysgen macro equivalence 85 (VS2.03.807) 
page seconds 199 (VS2.03.807) 
pageable frame shortage 168 (VS2.03.807) 
pageable frame stealing 169 (VS2.03.807) 
pageable link pack area (see also IEAPAKO00, IEALODOO, and 

IEALPAxx) 

advantages, uses, and recommendations 240 

ISAM pack list, recommended 241 

loading of 243 

module search sequence 243 
PAGEADD command 

overview 88 (VS2.03.807) 

page space shortage 118 (VS2.03.807) 

swap dataset 125.2 (VS2.03.807) 
PAGEDSN keyword 

DATASET macro instruction 115,116 (VS2.03.807) 

for primary PLPA copy 158.8 (VS2.03.807) 
PAGEDSN parameter 85 (VS2.03.807) 
page-out selection, page dataset 158.12 (VS2.03.807) 
page space shortage 118 (VS2.03.807) 
page/swap operations 158.1 (VS2.03.807) 
paging activity report (MF/1) 

description of 216 

how to useit 227 
Paging Activity Report 158.10 (VS2.03.807) 
paging data sets, size estimating 158.10 (VS2.03.807) 
paging devices 158.9 (VS2.03.807) 
paging I/Oerrors 158.11 (VS2.03.807) 


paging overhead, excessive 202.14 (VS2.03.807) 
paging rate J 
address space vs. Pageable System Area 202.10 (VS2.03.807) 
monitoring bySRM 165 (VS2.03.807) 
paging rates, comparison between problem 
program and system 261 
paging space 
adding 158.11 (VS2.03.807) 
dynamic allocation 158.12 (VS2.03.807) 
exhaustion 158.11 (VS2.03.807) 
minimum 117 (VS2.03.807) 
TSO requirements 158.7 (VS2.03.807) 
paging subsystem, monitoring by SRM 165 (VS2.03.807) 
PAGNUM parameter 
default value 119 (VS2.03.807) 
overview 88 (VS2.03.807) 
page space shortage 118 (VS2.03.807) 
syntax example 119 (VS2.03.807) 
sysgen macro equivalence 85 (VS2.03.807) 
value range 119 (VS2.03.807) 
parameters 
implicit 39-40 
operatorentry of 23 
parmlib (see individual member names) 
parmlib 
characteristics of each member, tabulated 27 
how members are created 25 
how tocontrolit 35 
member descriptions, detailed 41 
relationships to IPL parameters and sysgen parameters 25 
syntax rules, general 36 


PARMTZ » 
detailed description 144 : 


synopsis 33 
path, physical channel 166 (VS2.03.807) 
performance characteristics 

control over bySRM 162 (VS2.03.807) 

dispatching priority 162, 183 (VS2.03.807) 

performance period 184 (VS2.03.807) 

slope of objective 178, 180 (VS2.03.807) 
performance degradation 

duplexing 118 (VS2.03.807) 

paging space spillage 117 (VS2.03.807) 
performance factors 

catalog 257 

device allocation 252 

miscellaneous 303 

pageable link pack area 240 

TCAM 294 

VIO 246 
performance group 

definition 185 (VS2.03.807) 

guidelines for defining 202.4 (VS2.03.807) 

specification 202.18 (VS2.03.807) 
performance group number (PGN) 

assigning of 202.15 (VS2.03.807) 

default 202.16 (VS2.03.807) 

transaction definition 173 (VS2.03.807) 
performance group period (VS2.03.807) 

(see performance period) (VS2.03.807) 
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performance objective 

competition for resources controlled 

by 178-181 (VS2.03.807) 

cut-off workload level 202.2, 202.3, 177 (VS2.03.807) 

definition 176 (VS2.03.807) 

selecting service rates 202.2 (VS2.03.807) 

specification 202.17 (VS2.03.807) 

use of slope 202.2, 177 (VS2.03.807) 
performance period 

definition 184 (VS2.03.807) 

selecting durations 202.1 (VS2.03.807) 
performance recommendations, 

ASM _ 158.8-158.10 (VS2.03.807) 
PERFORM parameter, performance group 202.15 (VS2.03.807) 
period, performance group (VS2.03.807) 

(see performance period) (VS2.03.807) 
permanent I/O errors 158.7 (VS2.03.807) 

PGN parameter 202.20 (VS2.03.807) 

(see also performance group number) (VS2.03.807) 
placement of common areas 90 (VS2.03.807) 
PLPA 

(see also IEAPAKOO, IEALODOO, and IEALPAxx) 

advantages, uses and guidelines 240 

classification 158.1 (VS2.03.807) 

duplexed for recoverability 102.1 (VS2.03.807) 

loading 243 

location 90 (VS2.03.807) 

minimum paging space 117 (VS2.03.807) 

module search sequence 243 

page dataset 115 (VS2.03.807) 

paging data set size estimation 158.10 (VS2.03.807) 
preemption 180, 182 (VS2.03.807) 

(see also interval service value) (VS2.03.807) 
prevention, auxiliary storage shortage 158.11 (VS2.03.807) 
prevention of storage shortages, SRM 167 (VS2.03.807) 
PURGE (parameter in IEASYSxx) 120 
purging VIO data sets 22 (VS2.03.807) 


QSCECMP sysevent 271 
QSCEFL sysevent 273 
QSCEST sysevent 271 
questions and answers, ASM 
quick starts 
DUPLEX parameter 87 (VS2.03.807) 
prerequisite conditions for 116 (VS2.03.807) 
TPARTBLE 116 (VS2.03.807) 


158.11-158.12 (VS2.03.807) 


readback check 158.11 (VS2.03.807) 
ready jobs, average number of 189 (VS2.03.807) 
REAL (parameter in IEASYSxx; see also VRREGN) 121 
real storage 

default region size for an ADDRSPC=REAL job 128 
real storage, overcommitment of 202.14 (VS2.03.807) 
real time duration for performance period 202.9 (VS2.03.807) 
REC (parameter in SMFPRMxx) 149 
reclaim rate, definition of 216 
reconfigurable storage units 122 
RECONLIM (TSO parameter) 134 


reduction of data 
SGP program to reduce SMF data 261 
sysevent trace reduction 
rationale 264-265 
samples 289-293 
REGION parameter 158.7 (VS2.03.807) 
repeatability of service 
storage component 
CPU component 198 (VS2.03.807) 
replacing swap data sets 22 (VS2.03.807) 
reports, MF/1 (see also names of individual reports) 
descriptions of 209 
how to use them 224 
REQPGDAT sysevent 284 
REQSERVC sysevent 283 
REQSWAP sysevent 286 
request swap 164 (VS2.03.807) 
requirements, response and throughput 189, 190 (VS2.03.807) 
RESET command 202.16 (VS2.03.807) 
RESETPG sysevent 279 
resident time of a transaction 
resource factor coefficients 
definition 187 (VS2.03.807) 
guidelines for selecting 202.3 (VS2.03.807) 
specification 202.22 (VS2.03.807) 
resource manager constant 188 (VS2.03.807) 
resource shortages, prevention of 167 (VS2.03.807) 
resource use functions 165 (VS2.03.807) 
response-throughput bias (RTB) 
bottleneck elimination 202.15 (VS2.03.807) 
definition 183 (VS2.03.807) 
guidelines for use 202.3 (VS2.03.807) 
specification 202.20 (VS2.03.807) 
response time 
(see also TSO response time) (VS2.03.807) 
ISV 182 (VS2.03.807) 
MPL and domain weight 201 (VS2.03.807) 
performance objective 180 (VS2.03.807) 
performance period 186 (VS2.03.807) 
RESVBUF (TSO parameter) 134 
RFC parameter 202.22 (VS2.03.807) 
RMC parameter 202.22 (VS2.03.807) 
RMF 158.7-158.8, 158.10 (VS2.03.807) 
RMF reports 158.3 (VS2.03.807) 
Rotate dispatching priority 165, 202 (VS2.03.807) 
rotational position, slot 158.12 (VS2.03.807) 
RSMCNSTS sysevent 275 
RSTORCMP sysevent 273 
RSU (parameter in IEASYSxx) 122 
RTB parameter 202.20 (VS2.03.807) 
(see also response-throughput bias) (VS2.03.807) 


199 (VS2.03.807) 


174 (VS2.03.807) 


selecting ASM slots 158.12 (VS2.03.807) 
selection of candidates for permanent data 
sets 167 (VS2.03.807) 
service, comparison between problem program and system 262 
service 
computation 174 (VS2.03.807) 
definition 173 (VS2.03.807) 
establishing requirements 189 (VS2.03.807) 
maximum available,example 202.2 (VS2.03.807) 
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service bursting 158.2 (VS2.03.807) 
service burst length 158.8 (VS2.03.807) 
service definition coefficients 
defaults 197 (VS2.03.807) 
definition 174 (VS2.03.807) 
evaluation and adjustment 202.15 (VS2.03.807) 
guidelines for selecting 197 (VS2.03.807) 
specification 202.17 (VS2.03.807) 
service rate 
calculation 175, 202.2 (VS2.03.807) 
definition 174 (VS2.03.807) 
part of performance objective 176 (VS2.03.807) 
specified vs. measured 177 (VS2.03.807) 
service units 174 (VS2.03.807) 
SET command 38, 202.16 (VS2.03.807) 
SETDMN command 202.16 (VS2.03.807) 
shortage 
auxiliary storage, prevention 158.11, 167 (VS2.03.807) 
page space 118 (VS2.03.807) 
pageable frame, prevention 168 (VS2.03.807) 
SQA, prevention 168 (VS2.03.807) 
slope of a performance objective 177, 202.2 (VS2.03.807) 
slot 
rotational position 158.12 (VS2.03.807) 
selection, ASM 158.12 (VS2.03.807) 
usage snapshot 158.10 (VS2.03.807) 
slots, shortage of 168 (VS2.03.807) 
SMF 
as a Measurement tool to supplement MF/1 261 
data reduction program (SGP) 261 
parameter in IEASYSOO 123 
parameters in SMFPRMxx parmlib member 146 
SMFPRMxx 
detailed description 146 
overview 34 
snapshot of slot usage 158.10 (VS2.03.807) 
sources of page data set specifications 116 (VS2.03.807) 
space overspecification 158.9 (VS2.03.807) 
special purpose domains 202 (VS2.03.807) 
specification order for page data sets 115 (VS2.03.807) 
specific unit address, avoidance guideline 253 
SQA duplex page data set sizing 
consideration 158.7 (VS2.03.807) 
SQA 
parameter in IEASYSxx 124 
space shortage 124, 168 
SQALOW sysevent 276 
SQAOK sysevent 277 
SRM (see System Resources Manager) 
SRM page space shortage warnings 118 (VS2.03.807) 
SRM trace record, format and use 263 
SRV parameter 202.20 (VS2.03.807) 
start initiator commands 118 (VS2.03.807) 
stealing, pageable frame 169 (VS2.03.807) 
STEPCAT DD statement, use of to speed catalog search 258 
storage service units 174,198 (VS2.03.807) 
subclass of work, period duration 202.1 (VS2.03.807) 
subsystem 
defining requirements for 189 (VS2.03.807) 
domains for 200 (VS2.03.807) 
nonswappable 200 (VS2.03.807) 


SVC DUMP data set 100-102 
swap analysis 187 (VS2.03.807) 
swap counts, problem analysis 202.12 (VS2.03.807) 
swap data set 
replacement 22 (VS2.03.807) 
size performance aspect 158.3 (VS2.03.807) 
sizing example 158.8 (VS2.03.807) 
values 158.6 (VS2.03.807) 
SWAP DATA SET BAD message 125.2 (VS2.03.807) 
SWAPDSN parameter 85 (VS2.03.807) 
SWAP parameter 
description 125.1-125.2 (VS2.03.807) 
how specified 125.1 (VS2.03.807) 
minimum swap space 125.2 (VS2.03.807) 
overview 88 (VS2.03.807) 
swap space shortage 125.2 (VS2.03.807) 
syntax description 125.1 (VS2.03.807) 
syntax examples 125.2 (VS2.03.807) 
sysgen macro equivalence 85 (VS2.03.807) 
swap recommendation value 
calculation 187 (VS2.03.807) 
exchange swap 177 (VS2.03.807) 
workload level 177 (VS2.03.807) 
swapping 
analysis 187 (VS2.03.807) 
control of (see swapping frequency) (VS2.03.807) 
to control competition for resources 178-181 (VS2.03.807) 
types 163, 164 (VS2.03.807) 
swapping frequency 
cut-off level 202.1 (VS2.03.807) 
ISV 181, 188 (VS2.03.807) ' 
performance objective slope 181 (VS2.03.807) Jo 
resource factor coefficients 188 (VS2.03.807) 
swapping overhead, excessive 202.12 (VS2.03.807) 
SWINFL sysevent 272 
SWOUTCMP sysevent 272 
syntax example for the DUPLEX parameter 102.2 (VS2.03.807) 
syntax rules for IPS and OPT parameters 202.17 (VS2.03.807) 
SYQSCCMP sysevent 282 
SYQSCST sysevent 281 
sysevents 
meaning of the various sysevent codes 265-288 
sample data reductions 289 
tracing and data reduction 263 
sysgen 
CTRLPROG macro instruction 119 (VS2.03.807) 
DATASET macro instruction 125.1 (VS2.03.807) 
parameters that are copies to IEASYSOO 85 
relationships between sysgen parameters and parmlib 
members 25 
specifying page data sets 116 (VS2.03.807) 
SWAP parameter 125.1 (VS2.03.807) 
SYSLOG (operand of HARDCPY parameter in IEASYSxx) 104 
SYSP (parameter specified at IPL by the operator) 126 
System Activity Measurement Facility (see also MF/1) 
how to use it 203 
parameters, description of 135 
system contention factors 166 (VS2.03.807) 
system initialization (see initialization) 
system master catalog 102.2 (VS2.03.807) 


support, ASM for page data sets 118 (VS2.03.807) 
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system parameter list (IEASYSxx) 

detailed description 85 

overview of parameters 86 

synopsis 32 
system performance factors 231 
system resources, access to viadomains 161 (VS2.03.807) 
system resources manager (SRM) 

constants 202.23 (VS2.03.807) 

default IPS 202.4 (VS2.03.807) 

description 159 (VS2.03.807) 

functions 163 (VS2.03.807) 

guidelines for parameter selection 188 (VS2.03.807) 

installation management controls 202.15 (VS2.03.807) 

objectives 160 (VS2.03.807) 

parameter concepts 169 (VS2.03.807) 

parameter evaluation and adjustment 202.8 (VS2.03.807) 

parameter values and syntax 202.17 (VS2.03.807) 

types of control 161 (VS2.03.807) 
system throughput via mean-time-to-wait 
priority 165 (VS2.03.807) 
system tuning and the SRM 159 (VS2.03.807) 
SYSP operator command 

PAGE parameter 115 (VS2.03.807) 

PAGNUM parameter 119 (VS2.03.807) 
SYS1.DSSVM data set 152 (VS2.03.807) 
SYS1.DUMPnn data set 100-102 
SYS1.DUMPxx data set 152 (VS2.03.807) 
SYS1.PARMLIB (see also names of individual members) 

description of members 41 

synopsis 27 

use of (overview) 24 
SYS1.STGINDEX data set 

concatenation of 152 (VS2.03.807) 

in master catalog 260 (VS2.03.807) 
SYS1.VTAMLST 38 


target MPL 170 (VS2.03.807) 
task execution time 198 (VS2.03.807) 
TCAM 
changing parameters at START command 38 
tuning considerations 294 
teleprocessing paging data sets 158.9 (VS2.03.807) 
temporary page activity reference table 116 (VS2,03.807) 
Terminal I/O Coordinator parameters (see TIOC parameters) 
TERMWAIT sysevent 266 
TGETTPUT sysevent 281 
throughput control,SRM 162 (VS2.03.807) 
time interval for service rate 174,175 (VS2.03.807) 
time sharing 
how to start under MVS_ 38 
maximum number of logged-on users (USERMAX 
parameter) 134 
parameters (IKJPRMO00O) 131 
time sharing paging data sets 158.9 (VS2.03.807) 
time zone constant 144 
TIMEREXP sysevent 266 
TIOC parameters 131 
TOD (keyword in COMMNDxx) 
syntax and meaning 42 
use of 144 
TPARTBLE 116 (VS2.03.807) 


track overflow 
duplex page dataset 102.2 (VS2.03.807) 
page dataset 116 (VS2.03.807) 
swap dataset 125.1 (VS2.03.807) 
transaction 
definition 173 (VS2.03.807) 
duration of batch and TSO 202.1 (VS2.03.807) 
life span 184 (VS2.03.807) 
performance group 185 (VS2.03.807) 
performance period 184 (VS2.03.807) 
service used by 175 (VS2.03.807) 
time intervals defined for 175 (VS2.03.807) 
TSEVENTOO0 sysevent 265 
TSO 
allocation suggestions 255 
IPS service modifications 65 
parameters 131 
TSO, defining requirements for 189 (VS2.03.807) 
TSO domains, defining of 200 (VS2.03.807) 
TSO paging space requirements 158.7 (VS2.03.807) 
TSO response time 
(see also response time) (VS2.03.807) 
erratic 202.8 (VS2.03.807) 
impacted by paging overhead 202.10 (VS2.03.807) 
too good 202.9, 202.11 (VS2.03.807) 
poor 202.10 (VS2.03.807) 
TSO transactions, dispatching priorities 202 (VS2.03.807) 
turnaround time 
due to performance objective 180 (VS2.03.807) 
not good enough 202.11 (VS2.03.807) 
types of work, grouped into domains 161 (VS2.03.807) 


UIC (see unreferenced interval count) (VS2.03.807) 
under initiation, definition of 161 
unilateral swap count 202.12 (VS2.03.807) 
unilateral swap in 163 (VS2.03.807) 
unilateral swap out 163,202.12 (VS2.03.807) 
UNITNAME sysgen macro, use of 
defining separate esoteric subgroups 253 
specifying VIO datasets 249 
UNIT parameter 102.2 (VS2.03.807) 
UNIT specification 
DUPLEX parameter 102.2 (VS2.03.807) 
PAGE parameter 117 (VS2.03.807) 
SWAP parameter 125.2 (VS2.03.807) 
unreferenced interval count (UIC) 
definition 169 (VS2.03.807) 
analysis of overhead 202.14 (VS2.03.807) 
UNT, unit specification for the DUR 
parameter 202.21 (VS2.03.807) 
use attribute in VATLSTxx member 
definition 152 
position of parameter, meaning, and value range 156 
use characteristics, for domain creation 161 (VS2.03.807) 
USERMAX TSO parameter 134 
USERRDY sysevent 267 
utilization of resources 
adjusting functions 166 (VS2.03.807) 
evaluation 202.14, 202.15 (VS2.03.807) 
monitoring bySRM 165 (VS2.03.807) 
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VER default region size 128 
VAL parameter in IEASYSxx 127 
VATLSTxx 
detailed description 152-153 
synopsis 136 
used for non-demountable devices 151 
value, error buffer 158.6 
values 
page dataset 158.5 (VS2.03.807) 
page number, obtaining 119 
swap dataset 158.6 (VS2.03.807) 
VERIFYPG sysevent 279 
VIO 
advantages 246 
disadvantages 248 
how to specify VIO data sets 249 
performance considerations 248 
questions and answers 250 
window, definition and size 249 
VIO data set 


paging data set size estimation 158.10 (VS2.03.807) 


purging 22 (VS2.03.807) 
VOLSER parameter 102.2 (VS2.03.807) 


volume attribute list (VATLSTxx member) 151-153 


(see also VATLSTxx member) 


volume serial parameter in VATLSTxx member 157 


VRREGN parameter in IEASYSxx 128 
(see also REAL) 

VSAM 
format 102.2, 116 (VS2.03.807) 
swap dataset format 125.1 (VS2.03.807) 

VSAM catalog 
performance factor guidelines 257 
questions and answers 260 

VTAM 
default pack lists 79-80 
SYS1.VTAMLST 37 


warm starts 
DUPLEX parameter 87 (VS2.03.807) 
prerequisite conditions for 116 (VS2.03.807) 
TPARTBLE 116 (VS2.03.807) 


warning messages, page space shortage 118 (VS2.03.807) 


weight 
of domains (see domain weight) (VS2.03.807) 


of load adjusting recommendations 187 (VS2.03.807) 


of service components 174 (VS2.03.807) 


WKL, workload level specification 202.21 (VS2.03.807) 


WKLDCOLL sysevent 287 
WKLDINIT sysevent 287 
WKLDTERM sysevent 288 
workload activity report (MF/1) 
description of 220 (VS2.03.807) 
how to use it 228 (VS2.03.807) 
workload control,SRM 162 (VS2.03.807) 


workload levels 
competition for resources 178-181 (VS2.03.807) 
cut-off level 177 (VS2.03.807) 
definition 176 (VS2.03.807) 
relationship to performance objective 176 (VS2.03.807) 
specification 202.17 (VS2.03.807) 
swap recommendation value 177 (VS2.03.807) 
work sheets 191 (VS2.03.807) 
write-between-read logic 158.2 (VS2.03.807) 
WTL macro, maximum number allowed 109 
WTO buffers, number of 128 
WTOBFRS parameter in IEASYSxx 128 
WTORPLY 130 


OE1 completion code 158.4 (VS2.03.807) 
O3C wait state 158.4 (VS2.03.807) 
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